LM Synthetics
What is Synthetic Monitoring? Synthetic Monitoring is an active approach to testing a website or web service by simulating visitor requests to test for availability, performance, and function. Synthetic monitoring uses emulation or scripted recordings of user interaction or transactions to create automated tests. These tests simulate a critical end user pathway or interaction on a website or web application. The results of these tests give early insight into the quality of the end user experience by reporting metrics on availability and latency, and identifying potential issues. LM Synthetics monitoring leverages Selenium—a trusted open-source browser automation and scripting tool to send Synthetics data to LogicMonitor. LM Synthetics LogicMonitor uses the following Selenium tools for the Synthetics monitoring solution: Selenium GRID—Proxy server that allows tests to be executed on a device Selenium IDE Chrome Extension—Browser recording tool that allows you to create and run the synthetics checks The following diagram illustrates how LogicMonitor leverages Selenium to collect Synthetics data: Allows you to find out as soon as possible if any site/web service is having any issues Allows you to identify and solve problems quickly to prevent widespread performance issues. Allows for more uptime and proper working of your website Important factors for a website are page loading speed, performance and uptime. Gives you the ability to track metrics over time, viewing trends for further analysis Ping Checks Simple test to see if a website is up and running Alerts can be triggered based on if 1 or many locations are not able to ping the site insuring alerts are generated accurately. The checks can be triggered to run up to every 1 minute Website Checks Standard Web Check Displayed as “web checks” in LM interface Performed by one or more geographically dispersed checkpoint locations These locations are hosted by LM and external to your network Overall purpose is to verify that your website is functioning appropriately for users outside of your network and to adequately reflect these user’ experiences. Internal Web Check Performed by one or more collectors internal to your network Purpose is to verify that websites and cloud services (internal or external to your network) are functioning appropriately for users within your private network Selenium Checks Selenium synthetic checks are automated tests that use the Selenium web testing framework to simulate user interactions with a website or web application. These checks can be used to verify the functionality and performance of a website, such as checking that links are working properly, forms are submitting correctly, and pages are loading quickly. The tests can be run on a regular basis to ensure that the website is functioning as expected and to catch any issues early on. They can measure how long it takes to complete a specific workflow/task, such as logins, page loading, verifying specific text, validating users can input data. Selenium is the capstone item, they can check all end user access. This then segways into “we know there is a problem, now where is the problem”- enter APM/Logs. Ex. We get an alert that the login failed, now we would use other tools to figure out why/where. With the metrics, you will be able to tell exactly which check failed in the workflow process Selenium Synthetics Dashboard Adding Synthetics Website Test Common Use Cases MSP’s- tons of customers with different portals and keeping track with what's going on with all of those. They are meeting their SLA’s for uptime. If a customer has any kind of website they want to ensure is accessible all the time. Internal would be M365, or proprietary tool they built themselves. External- e-commerce website- clicking on promo link, check out sequence. You can also see trends over time and you can see busy parts of the day where a load balancer might be beneficial. Dev-ops might be interested in this and how it correlates with traces or push metrics we are sending. They can use synthetics as a “piece of the puzzle” to better understand the whole picture. The app teams may want to verify the login process of the application is functioning correctly Resources https://www.logicmonitor.com/support/services/adding-managing-services/adding-a-web-service https://www.logicmonitor.com/blog/ping-checks-vs-synthetics-vs-uptime#ping-checks-vs-synthetics https://www.logicmonitor.com/support/selenium-webchecks https://www.logicmonitor.com/support/selenium-synthetics-setup https://www.logicmonitor.com/support/lm-synthetics-overview © 2022 LogicMonitorConfidential and proprietarySynthetics - add ability to set device/group properties to reference in the .side file
With synthetic transactions, currently the only way to pass a value into the .side file is within the Authentication step during the initial creation of the synthetic check. The values can be referenced withthe credential.username/password/token variables in the .side file. This is pretty limiting, especially since it can only be defined during the initial check creation. If the password changes for my websites test user, I need to delete/recreate the check to redefine the authentication. This causes a loss of historical data. It would be a huge improvement if we could set a property on the synthetic check in LogicMonitor and then reference that property within the .side file. That way if I want to change the username or password for a check which involves a login, I don’t need to delete/recreate the check.Synthetics - add ability to update existing checks and download .side file via configsource
With synthetic transactions, currently you need to delete/recreate a check if we want to update it or change the username/password used for authentication. This causes loss of historical data and is difficult to manage. There are 2 things I would like to request that would make it easier for us to manage synthetic transactions. add ability to update an existing check. This includes updating the .side file or updating the authentication Add ability to download the .side file for an existing check via a companion Configsource. This would make it easier to resolve issues with a check and tweak it without impacting historical data.