ArcSight Monitor Thyself

Summary:

The document describes a comprehensive set of rules designed to monitor the caching state of infrastructure connectors, ensuring that they are functioning efficiently and avoiding issues such as excessive caching times or failures. Here’s an overview of how these rules interact and what each rule does in detail: ### Rule 3 - Infrastructure Connectors Cache - Failed Increment Counter - **Trigger**: This rule triggers when a connector has been continuously caching for more than two hours, as reported by Rule 2 (Infrastructure Connectors Cache - Failed). - **Purpose**: It increments a counter value associated with the active list to track the total number of connectors in cache. - **Variables Involved**: `getALCounterValue` for retrieving and `incrementALCounter` for updating the count. ### Rule 4 - Infrastructure Connectors Cache - Success Decrement Counter - **Trigger**: Activated when an entry from the "Infrastructure Connectors Currently Caching" or "Infrastructure Connectors Caching" lists is removed due to Rule 1a (Infrastructure Connectors Cache - Connector Cache Emptied). - **Purpose**: It decrements the counter, reflecting a reduction in the number of connectors being cached. - **Variables Involved**: `getALCounterValue` and `decrementALCounter`. ### Rule 5 - Infrastructure Connectors Cache - Number of Connectors Cache Active List Checker - **Trigger**: Activates whenever there’s a modification (increment or decrement) to the counter value in the "Infrastructure Number of Connectors Caching" list, as triggered by either Rule 3 or Rule 4. - **Purpose**: It checks for changes and updates based on these modifications. - **Variables Involved**: Interacts with active lists defined within the ESM schema. ### Rule 6 - (Not Detailed in Provided Text) - **Purpose**: This rule is not detailed in the provided text, but it likely involves evaluating a specific condition related to the number of connectors caching state. - **Variables Involved**: `flexNumber1` and possibly other flexible fields derived from data like `deviceCustomString4`. ### Rule 7 - Infrastructure Connectors Cache - Number of Connectors Cache Active List Checker (Specific Condition) - **Trigger**: Triggered when the conditions set in Rule 6 are met, where `flexNumber1` or a related field exceeds a certain threshold. - **Purpose**: It sets specific string fields based on this evaluation and updates other deviceCustomString fields to reflect connector cache status. - **Variables Involved**: Updates `deviceCustomString2` with priority settings if connectors have been caching for at least 2 hours. ### Rule 8 - Infrastructure Connectors Cache - Number of Connectors Cache Active List Checker (Mirror of Rule 7) - **Trigger**: Similar to Rule 7 but triggered when the condition is met in a different state, where `flexString2` equals "Daily GREEN". - **Purpose**: Sets `deviceCustomString2` to indicate a green status for connector cache. - **Variables Involved**: Updates based on the specific evaluation criteria. ### Summary of Key Variables and Actions: 1. **DeviceCustomString4 (DCS4)** is converted from string to long using `Convert_String_To_Long`. This data is crucial for aggregation in Rule 5 and potential evaluations in other rules like Rule 6. 2. **FlexNumber1** or similar flexible fields are used to evaluate conditions specified in Rules 6, 7, and possibly others. 3. **DeviceCustomString2** is dynamically updated based on the results of these rules, affecting visual indicators (like green or red icons) displayed on a dashboard for infrastructure connector cache status. ### Integration and Dashboard Feedback: - The system sets up `deviceCustomString2` as a key field declaration in the last state data monitor for Infrastructure Connector Cache Status. - This setup allows specific issues with connectors to be highlighted by displaying them as green if there is no caching issue, ensuring transparency and clear communication of cache status on the dashboard. ### Additional Notes: - The document mentions providing feedback through text messages or other forms of communication related to connector cache events. - Contacts for further assistance are provided at the end of the document, including information on how to comment using a specific text message code and contacting ArcSight Inc. This system is designed to automate monitoring processes, provide real-time updates on connector caching status, and ensure that infrastructure operations remain efficient and responsive by facilitating timely troubleshooting when issues arise.

Details:

This document, titled "Monitor ArcSight Infrastructure," outlines a comprehensive approach for monitoring and managing the infrastructure of ArcSight products. The main focus is on leveraging internal events generated by ArcSight products to ensure optimal performance, availability, and security. Here's a summary of its key points: 1. **Overview**: The document covers various aspects of monitoring ArcSight infrastructure including what to monitor, how to monitor components individually or via the Enterprise Security Manager (ESM), and the importance of using internal events for centralized views and drill-down capabilities. 2. **What to Monitor**: Key areas include availability (critical devices and infrastructure components like connectors, appliances, and ESM), performance metrics such as CPU usage, memory usage, network traffic including EPS (Events Per Second) in/out, disk usage, and storage free space. 3. **Monitoring Components Individually**: Detailed steps for monitoring each component are provided, emphasizing the importance of direct connections to devices and appliances, checking statuses, logs, CPU usage, disk space, memory statistics, network traffic, and event rates. 4. **Using ESM for Monitoring**: The document stresses the benefits of using internal events forwarded to ESM for a centralized view and overview summary. It suggests leveraging rules, reports, trends, and dashboards in ESM for detailed analysis and investigation capabilities. 5. **ArcSight Internal Events**: These are defined as events generated internally by ArcSight products. They include status monitor events providing system health statistics and audit events recording actions like user authentication or resource modifications. The document categorizes these events by product, detailing examples and how they can be monitored through connectors or directly connected to ESM. 6. **Configuration and Forwarding**: Instructions are given on how to configure the forwarding of internal events to ESM. This includes modifying properties for devices, connectors (direct, via appliance, or logger), appliances, and configuring multi-tier setups with ESM. The document also explains the importance of enabling device status monitoring by sending events through connectors. In summary, this guide is a comprehensive manual for maintaining and troubleshooting ArcSight infrastructure, focusing on leveraging internal event logs to ensure efficient operations across all connected devices, appliances, and servers. The provided document outlines the configuration steps and overview of internal events forwarding in ArcSight, focusing on both the Connector Appliance and Logger. For the Connector Appliance, the configuration involves several steps: 1. **Upload ESM Certificate**: This step requires uploading a certificate to the Connector Appliance. 2. **Add ESM Certificate**: The uploaded certificate is associated with a container. 3. **Add Syslog Connector**: Configure this connector as a Syslog type, directing it to the ESM (Enterprise Security Manager). Enable status monitor events for device status monitoring. 4. **Forward Audit Events**: Select the appropriate connector for forwarding audit events. For the Logger, the configuration steps include: 1. **Upload ESM Certificate**: Upload the certificate to the Logger Appliance. 2. **Add ESM Destination**: Create a connector pointing it to the ESM Manager. 3. **Add Forwarder**: Set up an ArcSight ESM (CEF) forwarder with specific queries and destinations. 4. **Forward Audit Events**: Select the ESM destination for forwarding audit events. ESM configurations differ based on whether it's a single-tier or multi-tier setup:

• **Single-Tier ESM**: No additional configuration is needed as internal events are already present.

• **Multi-Tier ESM**: Configure forwarding connectors with parameters like connector name, source and destination manager details.

The document also covers the "All Inclusive Connector/No Connector Caching State" use case, which aims to provide a unified view of caching states across various connectors. The content includes rules and active lists tailored for monitoring connector caching states, alerting on failures or successful operations. Overall, the document provides detailed guidance on setting up and managing internal events forwarding in ArcSight, with specific configurations for both Connector Appliance and Logger setups. This document discusses the state of connector caching within a system, detailing how connectors are monitored and managed when they start or stop caching data. The caching status is visually represented by an "All Inclusive Connector/No Connector Caching" icon on a dashboard, with additional monitoring via a query viewer that lists any connectors currently caching if the all inclusive icon turns red. The system uses three active lists to track connector caching: 1. **Infrastructure Connectors Currently Caching**: This list stores connectors actively caching data and expires entries after 2 hours of continuous caching. It updates every time a connector starts or stops caching, unless it has been in the list for more than 2 hours. 2. **Infrastructure Connectors Caching**: Unlike the first list, this one does not have an expiration timer and remains indefinitely until the connector cache is cleared or a specific rule triggers its removal. 3. **Infrastructure Number of Connectors Caching**: This active list tracks the total number of connectors constantly caching for over 2 hours, without any time limit set. The system employs several rules to manage these lists:

• **Rule 1** (Infrastructure Connectors Cache - Connector Caching - Rule 1): Triggered when a connector starts caching but is not already listed in the "Currently Caching" list. It adds details like the file name (connector name) and file path (connector URI) to this list.

• **Rule 1a** (Infrastructure Connectors Cache - Connector Cache Emptied - Rule 1a): Activated when a connector's cache is cleared, and it removes entries from both "Currently Caching" and "Caching" lists.

• **Rule 2** (Infrastructure Connectors Cache - Failed - Rule 2): This rule activates when a connector continues to cache for more than 2 hours, causing it to be removed from the "Currently Caching" list and triggering an internal event that adds details like the connector name and URI to another active list.

The document concludes with instructions on how to set up notifications or custom email templates to alert users when critical connectors are caching excessively, providing further detail on variable fields used in these rules. The document describes a series of rules designed to monitor the caching state of infrastructure connectors. Each rule is triggered under specific conditions to manage an active list that tracks the number of connectors currently in the cache or being cached. **Rule 3 - Infrastructure Connectors Cache - Failed Increment Counter**: This rule triggers when a connector has been continuously caching for more than two hours, as reported by Rule 2 (Infrastructure Connectors Cache - Failed). It increments a counter value associated with this active list to keep track of the total number of connectors in cache. Variables involved include getALCounterValue for retrieving and incrementALCounter for updating the count. **Rule 4 - Infrastructure Connectors Cache - Success Decrement Counter**: This rule is activated when an entry from the "Infrastructure Connectors Currently Caching" or "Infrastructure Connectors Caching" lists is removed due to Rule 1a (Infrastructure Connectors Cache - Connector Cache Emptied). It decrements the counter, reflecting a reduction in the number of connectors being cached. The process involves retrieving and updating the count using getALCounterValue and decrementALCounter respectively. **Rule 5 - Infrastructure Connectors Cache - Number of Connectors Cache Active List Checker**: This rule activates whenever there's a modification (increment or decrement) to the counter value in the "Infrastructure Number of Connectors Caching" list, as triggered by either Rule 3 or Rule 4. It checks for changes and updates based on these modifications. Each rule uses specific variables that interact with the active lists defined within the ESM (Enterprise Security Manager) schema to track connector caching status accurately. The rules are designed to ensure proper management of cached connectors, providing real-time information about which connectors are actively in use or need attention due to failure or excessive caching times. This system helps maintain operational efficiency and effective troubleshooting by automating monitoring processes related to data storage and retrieval mechanisms used within the infrastructure. The document describes a series of rules and processes used in the "Infrastructure Connectors Cache - Number of Connectors Cache Active List Checker" rule set, which is part of the "Infrastructure Connectors Cache - Red or Green Determinant" and related rules. Here's a summary: 1. **Rule 5**: This rule involves setting up variables to aggregate data on the number of connectors caching state. It uses the deviceCustomString4 (DCS4) field, which is converted from string to long using the Convert_String_To_Long variable. The results are used in later actions and need to be added to identical Aggregate fields for further processing. 2. **Rule 6**: This rule checks if the number of connectors caching state meets certain criteria by evaluating flexNumber1 (which is derived from DCS4). If the condition is met, it sets a string field based on this evaluation either to "Daily RED" or "Daily GREEN". The status determined in this step affects subsequent rules. 3. **Rule 7**: This rule triggers when Rule 6 conditions are met and flexString2 (derived from previous evaluations) equals "Daily RED". It updates deviceCustomString2 to reflect the connector cache status, setting a priority of 10 if connectors have been caching for at least 2 hours. The final state data monitor icon is set to red. 4. **Rule 8**: This rule mirrors Rule 7 but triggers when flexString2 equals "Daily GREEN". In this case, the system sets the deviceCustomString2 to indicate a green status for connector cache, which might be interpreted differently depending on context or configuration (not detailed in provided text). Overall, these rules are used within an infrastructure management framework to monitor and signal the state of connectors based on caching activities. The setup involves complex variable manipulations, conditional evaluations, and graphical icon updates based on specific conditions being met. This content is about setting up a rule for connector caching in a system using the terms and concepts found within it. It mentions creating custom strings, using specific fields to monitor infrastructure connectors' cache status, querying active list every minute, and displaying results on a dashboard with a green icon if there’s no connector caching issue. The process involves setting 'deviceCustomString2' to "Connector Cache Status" as a key field declaration in the last state data monitor for Infrastructure Connector Cache Status. This rule sets the name of the connector(s) causing issues to be displayed as GREEN on the dashboard, indicating good cache status. Additionally, there is information about providing feedback after an event or conference through a specific text message code and instructions on how to comment using it. There's also contact information for further assistance with use cases or contacting ArcSight Inc.

Disclaimer:

The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.