Best practices for network monitoring

Manual discovery uses the same mechanism as automated discovery, but it gives you more control. With manual discovery, you can run a bespoke agent ad hoc, which means that you can run it whenever you want and you can review and manipulate the results as needed. This is the preferred method for environments where tagging is prevalent or where there is a good amount of control from a centralized team adding new devices to the network. This reduces the need for full subnet scanning, which can be time-consuming and disruptive.

Pros

• Full control over the targets and results, including tag decoration.

• Helps to prevent possible devices that are not in scope for your monitoring footprint.

• Automated correlation to the proper SNMP profile for each device.

• Safety mechanisms are in place to prevent improper settings that could break your configuration file.

  Cons

• An administrator must run the agent on demand, and from the same host that your production agent runs on to ensure network/SNMP connectivity is tested properly.

• Moving the results from the discovery into the production configuration file is a manual process that requires a restart of the production agent in order to load the new settings.

  Example

  This discovery method follows the original deployment option for KTranslate agents. At a high level, the discovery process is:

1. Pull the latest version of the agent image to your local machine.

2. Copy the sample snmp-base.yaml configuration file from the image to your local machine.

3. Edit the configuration file to update the discovery section with the settings you need for cidrs and default_communities.

4. Launch a short-lived agent executing an ad hoc discovery job.

5. Edit any changes needed to the resulting devices in your configuration file.

6. Copy the new devices from your discovery configuration file into the production agent configuration file.

7. Restart your production agent to load the new settings.

   To use this method, follow steps on Manual container setup.

The last option is to skip the entire discovery process and manually add devices directly into the production configuration file. In practice, it is fairly rare to see this pattern in use as the standard discovery options automatically match devices to their profiles, and ensure that your configuration file is formatted correctly.

Pros

• Full control over the configuration of devices and their tag decorations.

  Cons

• Medium risk of misconfiguration in the settings. This method requires that you know the System Object Identifier (SysOID) of the device as well as understand the profile the device would target so you can identify which MIBs you want enabled (all of this is automated in discovery).

• Still requires a restart of the production agent to load the new settings.

  Example

  Here's an example of the device settings needed to successfully monitor an APC UPS:

  devices:
    ups_snmpv2c__10.10.0.201:
      device_name: ups_snmpv2c
      device_ip: 10.10.0.201
      snmp_comm: public
      oid: .1.3.6.1.4.1.318.1.3.27
      mib_profile: apc_ups.yml
      provider: kentik-ups
      user_tags:
        owning_team: dc_ops
  ...
  global:
  ...
    mibs_enabled:
      - IF-MIB
      - PowerNet-MIB_UPS
      - UPS-MIB

  카피

  중요

  global.mibs_enabled must be updated in order to start polling a MIB. When adding devices, you need to ensure this setting is updated with a list of distinct MIB names found throughout the associated SNMP profiles.

  Required settings are outlined in detail in our documentation for devices and global blocks.