edward_garza
EmployeeJoined 3 years ago
User Profile
Employee
User Widgets
Contributions
Re: Trouble with setHTTPProxy creating discovery script.
"setHTTPProxy" is an object method for the instantiated object, which in this case, the instantiated object is "httpClient". You need to instantiate the object first, then you can invoke methods on that instantiated object. The correct usage would be as follows: httpClient = HTTP.open(externalHost,443); <-- instantiating the "httpClient" object httpClient.setHTTPProxy("proxy name",8080); <--invoking the "setHTTPProxy" object method on the instantiated "httpClient" object14Views1like0CommentsRe: Docker Container Dynamic Groups by type.
Are the containers showing up as instances under the node running those containers? I ask because dynamic grouping only works for resources (the monitored node running the containers) and does not support instances (the containers running on the monitored node). Having said that, you can group the instances under the monitored node running those instances. We have a support guide for instance grouping under a resource. https://www.logicmonitor.com/support/devices/device-datasources-instances/instance-groups54Views7likes0CommentsRe: What are some of the most common use cases that our customers might be using to improve their business?
One of the use cases our customers use AIOps for is to quickly identify traffic pattern changes on important network interfaces such as the WAN links. AIOps can identify and alert when WAN links are dropping traffic or sending a higher than normal volume of traffic. This type of alerting goes beyond whether the WAN link is up or down.194Views1like3CommentsRe: I need to alert for 20 consecutive failed logon attempts within a 30 minute time period
If the SQL logs are ingested into LM Logs and the failed SQL login attempts are logged, then yes, you can set a log alert to notify when 20 failed SQL login attempts are seen in the log files within a 30 minute period.225Views5likes0CommentsDocker Collector Deployment Improvements
This post will provide additional configurations not covered in the LogicMonitor “Installing the Collector in a Container” support guide. Docker specific documentation can be found here https://docs.docker.com/engine. This post will not cover the Docker specific configurations such as creating a network. Support Guide Docker Container Collector Installation If you follow the support guide linked above to deploy a collector in a Docker container, you will be able to monitor resources using the Docker collector. However, if you have deployed a collector in a Docker container, and only followed the support guide linked above, you may have noticed the following items: The collector container is deployed to the default bridge network and this is not recommended for production use cases. The collector container by default is not set to perform any restarts. The collector container is not assigned an IP upon startup which will impact how LogicMonitor identifies the collector container resource if restarted with a different IP. The collector container is not provisioned to handle ingestion of syslog and netflow data. When viewing the collector in the “Collectors” tab, the collector is not linked to a resource. The “Device Name” of the collector is the container ID and a meaningful container hostname would be preferred. The collector is not listed anywhere in the Resource Tree, including “Devices by Type/Collectors”. If you look at the “Collectors” dashboard, the collector container metrics are not present. Screenshot Showing the Docker Collector Not Linked to a Resource Screenshot Showing Docker Collector Nowhere to be Found in Resource Tree Screenshot Showing Missing Docker Collector Metrics in “Collectors” Dashboard Improvements to the Docker Container Collector Installation The improvements for the items listed above are simple to implement. Here’s an existing example of a Docker command to deploy the collector in a Docker container that was created using only the support guide linked above. ### Example Docker Command Built Using Support Guide sudo docker run --name 'docker_collector' -d \ -e account='YOUR_PORTAL_NAME' \ -e access_id='YOUR_ACCESS_ID' \ -e access_key='YOUR_ACCESS_KEY' \ -e collector_size='medium' \ -e description='Docker Collector' \ logicmonitor/collector:latest Items 1, 2, 3, 4, and 6 in the list above are handled with additional Docker flags that should be added to the Docker example built using the support guide linked above. Let’s improve on the support guide example to resolve items 1, 2, 3, 4, and 6. Item 1 requires defining a network for the Docker container. This post assumes you already have a Docker network defined that you will attach the container to. The code example uses a network name of “logicmonitor”. Item 2 requires defining a Docker container restart policy. Docker has different options for the restart policy so adjust the code example to suit your environmental needs. Item 3 requires defining an IP for the Docker container. This post assumes you already have a Docker network defined where you will assign the container an IP valid for the network defined in your environment. The code example uses an IP of “172.20.0.7”. Item 4 requires defining port forwarding between the Docker host and the Docker container. The code example is using the default ports for syslog and netflow. Adjust to match the ports used in your environment. Item 6 requires defining a meaningful hostname for the Docker container. Here are the improvements added to the support guide code example to resolve items 1, 2, 3, 4, and 6. ### Improved to Define Container Network, Restart Policy, IP, ### Port Forwarding, and hostname sudo docker run --name 'docker_collector' -d \ -e account='YOUR_PORTAL_NAME' \ -e access_id='YOUR_ACCESS_ID' \ -e access_key='YOUR_ACCESS_KEY' \ -e collector_size='medium' \ -e description='Docker Collector' \ --network logicmonitor \ ## Item 1 --restart always \ ## Item 2 --ip 172.20.0.7 \ ## Item 3 -p 514:514/udp \ ## Item 4: syslog -p 2055:2055/udp \ ## Item 4: netflow --hostname 'docker_collector' \ ## Item 6 logicmonitor/collector:latest After you have deployed the collector with the additional Docker configurations to handle items 1, 2, 3, 4, and 6, items 5, 7, and 8 are resolved by adding the Docker container as a monitored resource in the LogicMonitor portal. Use the IP of the Docker container when adding the collector into monitoring. Adding the Docker container as a monitored resource will: Resolve item 5 by linking the Collector “Device Name” to the monitored Docker container resource Resolve item 7 by adding the Docker container to the Resource Tree and “Devices by Type/Collectors” group Resolve item 8 as the “Collector” datasources will be applied to the monitored Docker container and the metrics will be displayed in the Collectors dashboard Screenshot Showing the Docker Collector Linked to a Resource Screenshot Showing Docker Collector in Resource Tree Screenshot Showing Docker Collector Metrics in “Collectors” Dashboard170Views7likes1Comment