The ''address'': AnsibleUndefined error occurs due to SSH tunnels misconfiguration in uservars.yml. Fix this by removing undefined collectors and including all SSH tunnel collectors in the setup-hosts.yml playbook scope.
The 414 "Request-URI Too Large" error occurs when the URI requested exceeds the server's maximum allowed length. To resolve this, adjust the Nginx configuration by increasing the large_client_header_buffers directive to allow longer URIs.
Opsview version 6.8 has UTF-8 constraint issues causing errors in opsview-web database input validation. The fix involves replacing constraint files in /opt/opsview/corelibs/lib/ and restarting the opsview-web component.
Opsview 6.8.x enforces strict UTF-8 constraints causing regex errors with special characters like apostrophes and quotes. The issue can be resolved by applying provided file updates, restarting opsview-web, and reloading the browser.
Accessing the Opsview databases directly is possible but not recommended due to the risk of irreparable damage to the installation. Use the provided cx script or the API for safer access, and only connect as root when absolutely necessary.
Activating the Opsview software key can be done via the orchestrator command line using a specific activation command. You can verify license validity either through the command line or the Opsview UI on the My System: Subscriptions page.
Opsview does not support setting recurring downtime directly within the product interface. You can configure recurring downtime by using provided support scripts and scheduling them via crontab on the orchestrator.
Advanced deploy options in Opsview allow running playbooks against specific hosts or groups using hostnames, wildcards, and Ansible tags. The FAQ explains how to limit or exclude hosts with the -l option and use tags for precise targeting.
The Opsview Linux Agent may show a missing or incorrect desc= field when queried with the -H parameter. Installing the lsb_release package on the host and restarting the agent resolves this issue by restoring correct description information.
The Opsview-agent may return "NRPE: Unable to read output" when it receives data in an unrecognized format. Troubleshooting involves running the command manually on the end host to identify issues like missing packages or access problems.
Allowing external connections to the Opsview database via the orchestrator requires modifying the opsview-loadbalancer configuration, which does not accept outside connections by default. This article provides steps to enable external access while cautioning against direct database changes and recommending backups.
Apply Changes in Opsview applies pending modifications to monitoring settings and creates a backup of the opsview database. You can apply changes via the UI or command line, and troubleshoot stuck processes by removing specific files or restarting the opsview-orchestrator.
Autodiscoverymanager in Opsview may get stuck, causing scans to fail and the status to flip between Configured and Pending without running. The issue can be resolved by stopping autodiscovery, removing the pid file, and restarting autodiscovery to restore normal operation.
Backing up and restoring InfluxDB data in Opsview involves identifying and copying database shards for a specific time period. The process includes logging into the InfluxDB shell, locating the shard ID, and copying or restoring the shard files as needed.
The Opsview Collector Management page may display blank data, especially after an upgrade. To resolve this, refresh the browser cache using developer tools with either "Empty cache and hard reload" or by disabling the cache.
The BSM Message Queue Count service check shows critical status due to message queue buildup. Restarting the opsview-bsm component typically resolves the issue or use an event handler to automate restarts.
Users cannot log in through OAuth2 if the client secret keys have expired. Renew the keys in your OAuth2 realm and update the Opsview orchestrator configuration accordingly.
Reports fail to run due to blocked content caused by mismatched server hostnames. Updating uservars.yml with the correct server address and running the Orchestrator playbook resolves the issue.
Changing the InfluxDB retention period in Opsview adjusts how long time series data is stored to manage database size. This article provides steps to view and modify the retention period and how to drop shards after reducing it.
Opsview limits login attempts from an IP address before locking it out to prevent unauthorized access. You can change this maximum number by editing the uservars.yml file and applying the configuration with the orchestrator-install.yml playbook.
Changing the hostname or IP of nodes in an Opsview Collector Cluster requires manual steps. The process involves updating host info, stopping services, removing messagequeue/datastore, and running deployment playbooks on the orchestrator.
Check arguments within Agent (NRPE) usage can cause service check errors if arguments are not parsed correctly, especially with nested arguments. The FAQ explains the correct format and syntax, including using single quotes to encapsulate commands sent to the host.
Collection plans in Opsview configure and schedule host and service checks, event handlers, and notifications for collectors. They are stored as encrypted JSON files and updated by applying changes, with troubleshooting steps for update failures.
Collectors are distributed monitoring hosts that run service checks, receive results, and report them to the orchestrator. They share the monitoring load, provide resilience through clustering, and improve security by being placed near monitored hosts.
Collector CentOS 7 must be upgraded in-place to Oracle Linux 8 due to CentOS 7 end of life. The upgrade process involves preparing the system, running preupgrade checks, and completing migration with Opsview process management.
Collector clusters in Opsview are groups of collectors that share responsibility for monitoring assigned hosts, providing load sharing and resilience. If one collector fails, others maintain monitoring continuity, and cluster health is shown on the Monitoring Collectors page.
Collector Cluster Health in Opsview shows the status and alarms of individual Collector nodes and clusters, indicating ONLINE, DEGRADED, or OFFLINE states. The FAQ explains how to monitor queue backlogs, clear the cluster-health-queue, and interpret cluster health alarms for troubleshooting.
Collector node sanity checks in Opsview involve verifying cluster status to prevent split-brain issues by maintaining an odd number of hosts. The FAQ provides commands to check RabbitMQ and CouchDB cluster membership and node status on master/collector nodes.
Collector(s) offline in Opsview indicates a cluster-health issue that can have various causes. Troubleshooting involves checking connectivity, message queue status, version sync, disk space, system load, time synchronization, and system logs.
Opsview hosts run multiple microservices known as Opsview components. These components are managed by opsview-watchdog, which is also an Opsview component.
Configuring the Exchange Opspack involves setting up Kerberos authentication for agentless checks using WinRM on the Exchange Server. The FAQ provides step-by-step instructions for script execution, Kerberos configuration, and verifying connectivity to ensure successful monitoring.
Slack notification methods in Opsview support sending alerts to only one channel each. To notify multiple Slack channels, create additional Slack notification methods with unique variables for each channel's webhook URL and name.
The Teams notification method in Opsview supports sending notifications to only one Teams channel per method. To notify additional channels, create separate Teams notification methods by defining new webhook URL variables and configuring each method accordingly.
Creating good support tickets involves providing specific titles, detailed descriptions, and relevant evidence like errors, logs, and screenshots. This FAQ offers tips to help you submit clear, complete tickets that enable faster and more effective support.
The Opsview Housekeeping Cronjob Monitor service check goes critical if the housekeeping cronjob timestamp is outdated. Fixing permissions errors in backup directories allows the cronjob to complete and updates the timestamp, resolving the critical alert.
Data could not be sent to a remote host due to SSH authentication failure despite network connectivity. Verify correct /etc/hosts entries, SSH root login permissions, and proper SSH public key configuration.
SNMP traps may fail to insert into the Opsview database due to data exceeding the defined column length, causing processing and host assignment issues. The FAQ advises capturing raw traps with debug stdin2sock to identify and review problematic SNMP data.
Database-migrate playbooks may incorrectly report insufficient free space on the target filesystem during migration. The issue can be resolved by manually adjusting the disk space check path in the migratechecks.yml file and rerunning the playbook.
DBI connection failed due to the notifications user unable to access the notifications database. Resolve by setting up or disabling the Service Desk Connector module and verifying user permissions and password settings.
Deploy files contain all configuration used by opsview-deploy to install, update, and manage Opsview. The main deploy files include opsviewdeploy.yml, uservars.yml, and usersecrets.yml.
The deployment host is the host from which opsview-deploy runs. This host is typically the orchestrator in the Opsview environment.
Device backups may not appear in the Opsview UI due to uncommitted changes and locked files in the Netaudit (Rancid) component. The issue can be resolved by restarting the component, correcting file permissions, performing cleanup, and removing lock files.
Disabling the Change Log in Opsview requires administrator access to the Configuration > My System > Options page. You can disable it by unticking Enable Change Log, submitting changes with a message, and applying the changes.
The opsview-deploy command can modify the /etc/hosts files on Opsview hosts, but this behavior can be disabled. To prevent changes, set the opsviewhostupdateetchosts variable to False in uservars.yml, and manage hosts files manually thereafter.
Disabling the Service Desk Connector module prevents DBI connection errors in Opsview. This is done by editing uservars.yml, uninstalling the connector package, and reloading opsview-monit on the orchestrator.
Opsview Disaster Recovery installation and upgrade use semi-automated playbooks and scripts with ansible to ensure consistent configuration and reduce user error. The process requires SSH access, a licensed Opsview version, and following generated instructions from the primary server.
Dosh runs a specified command on selected Opsview hosts using the Ansible shell module and requires root access and the jq utility. The FAQ explains usage examples, prerequisites, and an alternative method using Ansible on the orchestrator.
The Downtime Manager may show a METRIC CRITICAL error with messages not being consumed and zero publish and deliver rates. The issue can be resolved by stopping the downtime manager module, purging the downtime-queue, and restarting the module.
The 'Output To Host File System' option is disabled by default when scheduling reports in Opsview. Enabling this option requires editing the applicationContext.xml file on the reports host and restarting the opsview-reportingmodule component.
The Change Log feature in Opsview prompts users to enter explanations for configuration changes. Enabling it adds an explanation column to the Audit Log and requires administrator access to activate.
Opspack imports using the UI are disabled by default in Opsview. Enabling this feature requires editing the uservars.yml file and running the orchestrator-install.yml playbook.
Enabling TLS 1.2 and TLS 1.3 while disabling older versions improves security in Opsview agents. This is done by editing configuration files and restarting the agent services on the host.
Error 500 'No closing quotation' occurs in Opsview 6.9+ when applying changes due to malformed NRPE plugin configurations. The issue is resolved by identifying and correcting or deleting the problematic plugin using argsanalyzer.py and the GUI.
The error decoding CSV occurs when running the checkhaproxy plugin in Opsview service checks. To resolve it, delete any temporary haproxy-related files in /opt/opsview/agent/tmp and rerun the service check.
Importing opspacks with passive checks via the Opsview UI causes an error due to a known bug. The workaround involves editing the config.json file to include a dummy check value before importing the opspack through the UI.
Service checks with new custom plugins in Opsview initially show errors if not assigned to any host. Assigning the check to a host and applying changes resolves the error and enables proper operation.
Exporting notifications from the Opsview UI is limited to a maximum of one full month of data due to retention and housekeeping policies. To export larger amounts of notification data, use the notificationsexport script from the datastore on the host.
Extending service check timeout in Opsview involves identifying the relevant collector servers and updating configuration files with precise indentation. After editing, restart the opsview-executor and opsview-agent on each collector, then apply changes in the UI to complete the process.
Failed to reload sysctl errors occur on Debian 9-10 during the opsview host sysctl config task. The issue is resolved by removing most IPv6 references from /etc/sysctl.conf or running a specific terminal command.
The Opsview collector machine.ref is stored locally on each host and also in the database. You can find a machine.ref by viewing the local file or querying the opsview.collectors database table.
Collector monitoring errors occur due to missing TLS certificates on some Collector nodes after upgrading. Running the fix682collectorkeys script copies required certificates and resolves the CHECK_NRPE client private key file error.
checkwmiplus.pl uses NTLMv1 by default but can be configured to use NTLMv2. NTLMv2 is enabled by editing service check arguments globally or per specific hosts in the web UI.
Gathering SSH host keys for target hosts may fail due to NAT or ssh-keyscan changes. Modifying the opsview-deploy file as root allows installation or upgrade to proceed.
Unauthorized session ID errors occur when Opsview logs out users due to IP address mismatches during login. The FAQ explains how to configure Opsview to ignore client IP validation by editing settings and restarting services.
Hard restarting all Opsview components on a host involves stopping services, killing processes, and removing leftover .pid and .lock files. This procedure ensures a clean restart of components to resolve startup issues caused by improper shutdowns.
Bulk importing hosts into Opsview can be done using a specially formatted spreadsheet with required sheets and columns. The process involves updating the spreadsheet, running an import script on the server, and reviewing results in a generated file.
Pulling Event data via the API allows retrieval within a specific time range. Use the API call with the correct date format to access precise Event information.
The SSL Unsupported Protocol Error occurs on old Opsview Agents due to unsupported SSL protocols. To resolve this, update to the latest Opsview Agent or configure the NRPE_PROTOCOL variable to allow only TLSv1 and apply the changes.
Using an SSL certificate from your own Certificate Authority can cause OAuth2 login errors in Opsview. Adding your CA certificate to the Mozilla CA bundle file resolves the authentication issue and enables successful login.
Using self-signed SSL certificates between the opsview-agent and infrastructure-agent requires specific configuration changes. This includes updating agent variables, adjusting cipher lists, modifying the infrastructure-agent YAML file, and restarting services to establish secure communication.
Using self-signed SSL certificates with the Infrastructure Agent requires specific configuration changes. Adjust agent settings, omit CA certificates, and restart the agent to enable self-signed certificate use.
Creating a custom monitoring plugin in Opsview involves writing scripts in languages like bash or python to extend monitoring capabilities. This guide provides example scripts for reference but clarifies they are informational and not official product components.
Identifying hosts monitored by a specific collector cluster in Opsview can be done using the API query, orchestratorclusterhosts script, or a database query. The FAQ provides detailed steps for each method, including prerequisites and cautions for direct database access.
Importing Opspacks can be done via the UI or command line with valid file extensions. The process includes uploading or transferring files and using specific scripts for multiple Opspacks.
Infrastructure Agent custom *nix installations cover compiling and configuring agents for unsupported operating systems using source code tarballs. The FAQ provides general and OS-specific steps to install, start, and verify the agent, including service setup and dependency management.
Infrastructure Agent logging can be customized by modifying options like maxBytes, backupCount, filename, and encoding in YAML configuration files. Linux uses syslog by default, while Windows and Linux file logging allow direct control over log rotation and file settings.
Adding custom PowerShell plugins to the Windows Infrastructure Agent enables tailored monitoring. The process involves placing scripts in the plugins folder, configuring agent.yml, and setting up service checks in the Opsview UI.
Installing a Remote Collector Cluster from an offline repository involves hosting the package repository on the Orchestrator to support secure environments without external access. The guide details configuring the repository, updating dataserver settings, and registering collectors to complete the installation.
Installing Opsview support scripts requires different steps based on whether your orchestrator or collector has internet access. The FAQ provides detailed instructions for both online and offline installation processes, including directory setup and command usage.
NSCA allows host and check results to be sent into Opsview Monitor from remote sources. Installation involves setting up the opsview-nsca package, configuring the password in nsca.cfg, and enabling the NSCA daemon.
Opsview Agent is not available for Ubuntu 22.04 but can be installed using the Ubuntu 20.04 package. The process involves adding the Focal repository and resolving dependency errors during installation.
Opsview no longer supports SMS functionality by default since version 6.0. You can install the SMS plugin from OP5 Monitor to enable SMS notifications in Opsview.
IP mismatch errors occur when a collector uses its hostname but the SSL certificate expects a matching IP address, causing certificate verification to fail. Redeploy the collectors with the correct configuration to resolve the issue.
Bulk edit of many hosts in Opsview may fail to complete due to a database deadlock error. Increasing the MySQL/MariaDB innodb_lock_wait_timeout parameter can resolve this issue.
Listing all URLs in Opsview involves running a specific SQL query on the hostattributes table via the orchestrator and database connection. The FAQ provides a step-by-step guide to extract, export, and prepare the URL data for monitoring or auditing.
Listing the durations of past Apply Changes helps determine if the current Apply Changes process is taking longer than usual. You can query the reloadtimes table in the opsview database to view these durations using the orchestrator.
Machine.ref is a unique identifier assigned to each Opsview host and stored locally in the machine.ref file. It helps identify which Opsview host a message queue relates to and is referenced as collector\ref in the database.
Collector hosts files must be manually managed if opsview-deploy changes are disabled to ensure proper communication and resolution. The process involves verifying hostnames, adding 127.0.1.1 entries, and confirming hostname resolution across the collector cluster.
The METRIC UNKNOWN error occurs when the collector's system time does not match the orchestrator's time. Correct the system time on the collector to resolve the Message Queue API call failed status 400 error.
METRIC UNKNOWN - RegistryError occurs due to incorrect registry password in orchestrator.yaml. Upgrading to Opsview 6.12.1+ or updating the password and applying changes resolves the issue.
Monitoring MySQL with require_secure_transport enabled requires additional configuration on CentOS/RHEL 7 systems. Proper certificates with FQDN or SAN and plugin adjustments ensure secure plugin functionality.
Moving all hosts monitored by one collector cluster to another is necessary when removing a collector cluster. This can be done using Opsview's REST API or by carefully updating the database, followed by applying changes.
Moving hosts between Collector Clusters can be done via the command line on the Opsview Orchestrator using the move\device\between\servers script. After moving hosts, run Apply Changes to update Collection Plan files and ensure monitoring continuity.
The Netaudit page shows blank due to backend repository corruption in DR Systems. The resolution involves dumping and restoring the repository to remove the corrupted commit and fix the sandbox.
The Netaudit page in Opsview shows blank due to backend repository corruption caused by the syncdrnodes job running on both orchestrator nodes. The resolution involves dumping and restoring the repository and fixing the checked out sandbox on the primary node.
Newly set collectors in Opsview 6.10.1+ fail to establish RabbitMQ connections due to missing cluster users on the orchestrator. Running the MQ install playbook with a locked uservars.yml version resolves the connectivity issue.
Nightly housekeeping in Opsview can cause the "Import Runtime" service check to fail due to database deadlocks between housekeeping and import runtime cronjobs. The resolution is to update the import runtime cronjob to exclude the housekeeping time window, preventing conflicts.
Setting a service check to a soft state via the REST API is no longer supported. The Opsview UI still allows soft states before hard states after recheck attempts.
Notifications are sent for checks despite downtime being set and visible in the UI due to a mismatch between the database and collector datastore states. Running the recreatedowntime script restores downtime in the collector datastores to suppress notifications properly.
ODW Datasource Configuration errors occur due to connectivity issues or the database being offline. Use the "Test Connection" option to validate the URL, username, and password settings, then save changes and rerun the report.
ODW_STATUS CRITICAL indicates issues with the import/runtime or housekeeping processes in Opsview. Troubleshoot by checking running processes, reviewing fatal errors in logs, adjusting crontab timings, and manually running import/runtime.
Open collector firewall ports are required for communication between the collector and the orchestrator in Opsview. This article provides step-by-step commands to open the necessary ports on CentOS, RHEL, Ubuntu, and Debian systems.
The notification method user field in Opsview 6.8.x does not allow the '@' symbol due to a UTF-8 implementation issue. Applying the provided patch on the Opsview master resolves the validation error and allows usernames with '@' symbols.
Opsview Disaster Recovery installation and upgrade require a valid Disaster Recovery agreement and use Ansible playbooks for a semi-automated, standardized deployment process. The FAQ details prerequisites, installation commands, configuration generation, and differentiates legacy from playbook-based DR setups.
An Opsview environment consists of all your Opsview hosts combined. Each environment requires a separate license.
Opsview hosts are any hosts running Opsview components except those running only the Opsview agent. This includes orchestrators, collectors, and remote databases, which together form the Opsview environment.
Opsview version 6.11.7 has an issue preventing scheduled downtime from being applied directly to service checks. The workaround involves scheduling downtime at the host level and selecting service checks through the host’s downtime menu.
Opsview_deploy.yml contains server-specific configuration settings for Opsview. It may override global configurations defined in the uservars.yml file.
Opsview versions below 6.11.5 have a memory leak issue in the opsview-notifyd process. The issue can be resolved by scheduling restarts of the opsview-servicedeskconnector or disabling the Service Desk Connector module.
Opsview versions 6.4 to 6.6.6 have a memory leak in the opsview-freshnesschecker process. Scheduling a daily restart of the opsview-freshnesschecker component resolves the memory usage growth issue.
Opsview-webserver fails to start due to incorrect Nginx configuration caused by playbook task order. Manually install opsview-dataserver, then re-run the playbook to resolve the startup failure.
The Orchestrator manages configuration, hosts the Nginx webserver for the UI, creates collection plans, functions as a collector, and load balances database connections in Opsview. It operates as the Master Monitoring Server in its own collector cluster.
Phantom downtime causes monitored hosts to show downtime without user attribution or expiry dates. Running the phantomdowntime support script on the orchestrator resolves existing phantom downtime issues.
Phantom downtime occurs when hosts or services show downtime incorrectly in Opsview. The script detects phantom downtime and creates a short downtime instance to clear it automatically after one minute.
Opsview removes plugins placed manually in /opt/opsview/monitoringscripts/plugins after Apply Changes starting from version 6.8.8. Custom scripts must be imported via the Opsview UI to ensure they are stored in a persistent directory and retained.
Rebuilding database replication in Opsview involves stopping replication, exporting and importing the database, and resetting replication settings on primary and secondary hosts. The process requires root access, use of screen sessions, and verification of replication status to ensure successful synchronization.
Reclaiming disk space after disabling the Opsview Data Warehouse (ODW) involves removing retained data from the ODW database. This guide explains how to safely delete all ODW data using the dbodw script to free disk space immediately.
Recreate_downtime allows you to fetch, delete, and recreate all downtime currently registered in Opsview. This process works around issues caused by moving hosts between clusters or rebuilding datastores.
Reducing datastore and messagequeue nodes in an Opsview Collector cluster addresses replication issues in high latency networks. The process involves reconfiguring cluster nodes via the Orchestrator and UI, then applying changes to ensure proper component distribution.
Apply Changes fails if the reloadflag file exists, indicating a reload is already in progress. To resolve this, check for an active orchestratorgenerate process and remove the reloadflag file if no reload is running.
Components that are uninstalled may still appear on the list in Opsview. Reloading the list removes the component and deletes its associated .conffile from the services directory.
Removing a collector cluster in Opsview requires deleting or moving all monitored hosts from the cluster before deactivating and deleting the cluster and its collectors. The process includes updating deploy files and shutting down affected collectors to complete the removal.
Removing a collector from a multi-collector cluster involves editing the cluster in the Opsview UI and deleting the collector. The process includes updating deploy files and running the setup-everything.yml playbook to apply changes.
Removing logs with future dates in Opsview involves manually deleting entries from the runtime database tables nagiosstatehistory and nagiosservicechecks. The FAQ provides steps to identify and delete these entries to resolve issues caused by incorrect manual date settings.
Opsview Rest API queries return only 50 rows by default when listing hosts. To retrieve all rows, include rows=all in the query parameters.
Opsview Rest API access can be controlled using roles to restrict users to read-only permissions, preventing unauthorized configuration changes. Assigning a read-only role in the Opsview UI limits API commands to GET requests while denying POST, PUT, and DELETE actions.
Restoring a backup from the audit log reverts changes saved by an Apply Changes using backups stored on the orchestrator. The process involves selecting the backup in Configuration > Audit Log, clicking Restore, and then applying changes.
Saved parameters do not load in the browser when editing a scheduled report in Opsview. A shell script and SQL query can display the stored parameter values as a workaround.
Sending an empty collection plan to a collector verifies communication between the orchestrator and the collector’s scheduler. The process involves restarting the opsview-scheduler, identifying collectors, and using orchestratorgenerate to send empty plans to each collector.
Setting different landing pages for user roles controls what users access after logging in to Opsview. Assign roles, install support scripts, and run a CLI command to redirect users to their specified landing page.
Setting up Splunk notifications in Opsview involves installing the notifybysplunk script and configuring notification methods, users, and profiles in the UI. The FAQ provides step-by-step instructions for different Opsview versions, including how to add supplemental text for specific checks.
Setting exceptions on service checks in Opsview allows you to customize monitoring behavior for specific hosts and services. You configure exceptions by editing the host configuration, selecting the service check, and adjusting the exception arguments in the Exceptions section.
Setting up OAuth2 in Opsview to use UserPrincipalName (UPN) instead of Email as the username requires specific configuration. For the latest setup instructions, contact Opsview Support referencing JIRA OP-54881.
Disk monitoring setup in Opsview automatically updates %DISK% host variables by scanning devices with assigned disk checks. The scan uses checknrpe, checkdisk, or SNMP to gather filesystem data and updates hosts accordingly.
The Windows Drive service check nsc\checkdrivesize can display total disk size in the Status Information section. Adding ShowAll=long to the service check configuration enables showing total disk size alongside used disk size in the Results tab.
SNMP traps are only processed by the master trap node in an Opsview collector cluster. Limit SNMP trap daemons to two collectors and send traps to both to prevent drops.
Support scripts in Opsview are additional tools installed under /opt/opsview/supportscripts to assist with incident and problem investigation. These scripts provide extra functionality to help diagnose and resolve issues.
Collector clusters in Opsview should have an odd number of collectors to ensure resilience and avoid split-brain issues. Clusters with two collectors are unsupported, and even-numbered clusters above two are supported but not recommended due to quorum loss risks.
The Timeseriesrrd-housekeeping script removes old and unused RRD files from the timeseries server to reduce disk space usage. You can automate this cleanup by scheduling the script with cron and adjust retention days to manage data storage.
High CPU or memory usage by the beam.smp process can increase system load on Opsview collectors. Running housekeeping commands temporarily reduces resource use, but monitoring and further troubleshooting may be needed if the issue recurs.
Turning off an Opsview collector requires stopping all Opsview components first to ensure a safe shutdown. Use opsview-monit to stop all components and verify they are not monitored before powering off the host.
The error "You must specify a changelog for any changes" occurs when running setup-monitoring.yml with Change Log enabled. Temporarily disable the Change Log, run the playbook, then re-enable the Change Log to resolve this issue.
The Service Desk Connector in Opsview stops sending notifications after upgrading Jira to version 9 due to a deprecated API endpoint. The workaround involves replacing the Jira.pm file with an updated version and restarting the opsview-servicedeskconnector component.
Updating support scripts in Opsview depends on whether your orchestrator has an internet connection or not. The FAQ provides step-by-step instructions for both online updates using the updatesupportscripts script and offline updates via file transfer and command line.
Upgrading the Opsview Collector from Ubuntu 18.04 to 20.04 involves an in-place upgrade process with specific steps to ensure compatibility. The procedure includes backing up, updating the OS, rebooting, verifying Opsview processes, and applying changes in the UI.
Upgrade errors occur when the orchestrator has a different database client than the remote server. Removing the old client before installing the new one resolves the issue on CentOS7, RHEL7, Ubuntu20, and Debian10 systems.
User_secrets.yml stores credentials used by Opsview. It contains sensitive information required for Opsview operations.
User_vars.yml contains system-wide customizations for the Opsview installation. It defines configuration settings that apply across the entire Opsview system.
Opsview Monitor requires TLSv1.2 for communication, causing older agents to fail without configuration changes. Downgrading to TLSv1.0 is possible using a workaround, but upgrading agents to support TLSv1.2 is recommended.
Variables longer than 64 characters can prevent the setup-monitoring.yml playbook from completing successfully. The issue is related to bug OP-65414 and requires updating two yaml files to ignore the problematic variable as a workaround.
The components running on the primary and secondary Opsview Disaster Recovery orchestrators differ and must switch during failover. The primary orchestrator runs all Opsview components, while the secondary runs only specific components like opsview-watchdog and opsview-messagequeue.
Backups fail in Opsview due to missing RELOAD permission for the opsview user in MySQL 5.7.41 and 8.0.32. Upgrading MySQL or granting RELOAD permission to the opsview user resolves the backup failure issue.
Sharing a dashboard fails if another user currently has it open, indicated by the "USED BY" field in Opsview. To resolve this, clone the dashboard, have users close it, or add panels to an existing dashboard before sharing.
Collectors may show the wrong Opsview version in the UI if the opsview-scheduler package version does not match the expected release version. To resolve this, verify package versions, update if needed, and restart the opsview-scheduler component on the collector.
Opsview may fail to start after a host restart due to leftover .pid and .lock files. Performing a hard restart of all Opsview components on the host resolves this issue.
Memory usage on the orchestrator can be high due to known memory leaks in Opsview 6.6.6 or older. These issues involve opsview-freshnesschecker and opsview\notifyd and are noted on the Fixed Defects page when resolved.
API queries may return more information than expected if the filters used are invalid. Refer to the Opsview API documentation for correct filter examples to ensure queries return the intended filtered results.
New license keys may not immediately appear in the Opsview UI under Configuration > My System > Subscriptions. To update the display, remove old license files and refresh the Subscriptions page to force detection of the latest key.
Sync_monitoringscripts.yml takes longer in Opsview 6.7.5 due to enhanced security changes. Use rsync commands or the legacy sync playbook to copy specific folders faster.
The option to delete the last collector in an Opsview cluster is greyed out. Use the previous version's collector management URL to delete the collector and update deploy files accordingly.
The error caused by a hyphen at the start of the secret key in Azure Monitoring can disrupt service checks. Adding an "=" after the secret key in the command and updating the database resolves this issue.
Opsview limits the number of concurrent login sessions, defaulting to 10 sessions. You can resolve session limits by using API authentication tokens or increasing the maxsessions value in uservars.yml.
No FAQs match your search.