SNMP Poller

The SNMP Poller microservice discovers SNMP devices for the Discovery Service microservice and periodically polls the discovered devices for availability.

This microservice is part of the Discovery microservice pipeline. It uses a worker-coordinator design to balance workloads and allow for scaling. You deploy instances of this microservice and others in the same pipeline to separate clusters for each device zone. See Understanding the Discovery Pipeline in Unified Assurance Concepts for conceptual information.

You can enable redundancy for this microservice when you deploy it. See Configuring Microservice Redundancy for general information.

Autoscaling is supported but disabled by default for this microservice. You can optionally enable autoscaling when you deploy the microservice. See Configuring Autoscaling and SNMP Poller Autoscaling Configuration.

This microservice provides additional Prometheus monitoring metrics. See SNMP Poller Self-Monitoring Metrics.

SNMP Poller Prerequisites

Before deploying the microservice, confirm that the following prerequisites are met:

1. A microservice cluster is set up. See Microservice Cluster Setup.

2. The following microservices are deployed:

   • Pulsar

   • Discovery Service

Deploying SNMP Poller

To deploy the microservice, run the following commands:

su - assure1
export NAMESPACE=<namespace>
export WEBFQDN=<WebFQDN> 
a1helm install <microservice-release-name> assure1/snmp-poller -n $NAMESPACE --set global.imageRegistry=$WEBFQDN

In the commands:

• <namespace> is the namespace where you are deploying the microservice. The default namespace is a1-zone1-pri, but you can change the zone number and, when deploying to a redundant cluster, change pri to sec.

• <WebFQDN> is the fully-qualified domain name of the primary presentation server for the cluster.

• <microservice-release-name> is the name to use for the microservice instance. Oracle recommends using the microservice name (snmp-poller) unless you are deploying multiple instances of the microservice to the same cluster.

You can also use the Unified Assurance UI to deploy microservices. See Deploying a Microservice by Using the UI for more information.

Changing SNMP Poller Configuration Parameters

When running the install command, you can optionally change default configuration parameter values by including them in the command with additional --set arguments. You can add as many additional --set arguments as you need.

For example:

• Set a global parameter described in Default Global SNMP Poller Configuration by adding --set configData.<parameter_name>=<parameter_value>. For example, --set configData.LOG_LEVEL=DEBUG.

• Set a coordinator-specific or worker-specific parameter by prefixing configData in the argument with coordinator or worker. For example, --set coordinator.configData.LOG_LEVEL=DEBUG. This overrides the global parameter.

• Enable redundancy for the microservice by adding --set redundancy=enabled.

• Enable client-side (worker) or server-side (coordinator) keep-alive checks by adding --set configData.GRPC_CLIENT_KEEPALIVE=true or --set configData.GRPC_SERVER_KEEPALIVE=true. See About Keep-Alive Configurations.

• Enable autoscaling for the microservice and set the maximum replica count to an appropriate value for your environment by adding --set autoscaling.enabled=true --set autoscaling.maxReplicaCount=<N>. See SNMP Autoscaling Configuration for information about choosing an appropriate value for <N>.

Default SNMP Poller Configuration

Some SNMP Poller configurations apply to workers and coordinators, some apply only to coordinators, and some apply only to workers. The parameters set for the workers or coordinators specifically override the global parameters. For example, if you set global log levels to DEBUG, but the log level for coordinators to INFO, then the coordinator logs will use INFO and worker logs will use DEBUG.

Default Global SNMP Poller Configuration

The following table describes the default global configuration parameters found in the Helm chart under configData for the microservice. These apply to both workers and coordinators.

About Keep-Alive Configurations

By default, the coordinator and individual workers periodically send heartbeat messages between each other, with no validation, to check that the connection is not idle. To validate the connection, you can optionally enable ping-based gPRC keepalive checks, which expect a response within a configurable timeframe. If no response is received, the connection is considered down and the workers attempt to reestablish communication.

In the SNMP Poller microservice, the coordinator acts as the gPRC server and the workers act as clients. You enable keepalive checks from the coordinator to workers in the GRPC_SERVER_KEEPALIVE parameter and from workers to the coordinator in the GRPC_CLIENT_KEEPALIVE parameter. You set the interval at which the checks are made in the GRPC_SERVER_KEEPALIVE_TIME and GRPC_CLIENT_KEEPALIVE parameters, and the time within which a response is expected in the GRPC_SERVER_KEEPALIVE_TIMEOUT and GRPC_CLIENT_KEEPALIVE_TIMEOUT parameters.

Client-side keepalive checks have mandatory enforcement policies. If the client checks too frequently, the connection will be dropped with an ENHANCE_YOUR_CALM(too_many_pings) error. When you enable client-side keepalive checks, the SNMP Poller automatically sets the enforcement policy to allow no more than the value of GRPC_CLIENT_KEEPALIVE_TIME minus the value of GRPC_CLIENT_KEEPALIVE_TIMEOUT.

Default SNMP Poller Coordinator Configuration

The following table describes the default configuration parameters for coordinators found in the Helm chart under configData for the microservice.

Default SNMP Poller Worker Configuration

The following table describes the default configuration parameters for workers found in the Helm chart under configData for the microservice.

SNMP Poller Autoscaling Configuration

Autoscaling is supported for the SNMP Poller microservice. See Configuring Autoscaling for general information and details about the standard autoscaling configurations.

For SNMP Poller, KEDA also uses the snmp_coordinator_metric_workers_required Prometheus metric to make scaling decisions. This metric is set dynamically. The SNMP Poller Microservice coordinator assigns polling and discovery workers during resynchronization with the Unified Assurance database. Numbers are based on polling throughput and your configuration settings as follows:

• Number of poller workers: The number of unique devices being polled divided by the WORKER_CONCURRENCY value. The result is rounded up to the nearest whole number.

• Number of discovery workers: The number of poller workers, multiplied by the DISCOVERY_WORKERS_PERCENTAGE value, divided by 100. The result is rounded up to the nearest whole number.

• Total workers: The number of polling workers plus the number of discovery workers. This exposed as the snmp_coordinator_metric_workers_required Prometheus metric.

When you deploy the SNMP Poller microservice with autoscaling enabled, you must also calculate total workers required, based on the expected number of devices that will be polled in the device zone, to determine the value to use for the maxReplicaCount autoscaling configuration setting.

For example:

• For 100,000 polled devices, when WORKER_CONCURRENCY is set to 2000 and DISCOVERY_WORKERS_PERCENTAGE is set to 25:

  • Total required workers and maxReplicaCount value: 63

  • Polling workers: 50

  • Discovery workers: 13

• For 250,000 polled devices, when WORKER_CONCURRENCY is set to 3000 and DISCOVERY_WORKERS_PERCENTAGE is set to 33:

  • Total required workers and maxReplicaCount value: 112

  • Polling workers: 84

  • Discovery workers: 28

Modifying Scaling Triggers

By default, only the snmp_coordinator_metric_workers_required metric is configured as an autoscaling trigger. You can define additional triggers in the Helm chart by adding them under the triggers section.

For example, the default trigger configuration is:

autoscaling:
  ...
  triggers:
    - type: prometheus
      metadata:
        metricName: required_total_workers
        serverAddress: http://prometheus-kube-prometheus-prometheus.a1-monitoring.svc.cluster.local:9090
        query: snmp_coordinator_metric_required_total_workers
        threshold: '1'
        metricType: Value

SNMP Poller Self-Monitoring Metrics

The SNMP Poller microservice exposes the self-monitoring metrics for coordinators described in the following table to Prometheus.

Each of the metrics in the table is prefixed with snmp_coordinator in the database. For example, the full metric name in the database for the first metric is snmp_coordinator_metric_worker_count.