> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apinizer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> You can monitor the general health status of the system, detect anomalies, trigger actions when specified threshold values are exceeded, and check whether APIs are continuously running.

## Monitoring Modules

Apinizer Monitoring modules are used to monitor the general health status of the system, detect anomalies, and trigger actions when specified threshold values are exceeded.

<CardGroup cols={2}>
  <Card title="API Health Check" icon="heart-pulse" href="/en/monitor/api-health-check">
    Automatically checks whether APIs and web services are continuously running
  </Card>

  <Card title="Anomaly Detector" icon="shield-check" href="/en/monitor/anomaly-detector">
    Automatically detects abnormal behaviors in API traffic
  </Card>

  <Card title="Alarm" icon="bell" href="/en/monitor/alarm">
    Sends notifications when specified threshold values are exceeded
  </Card>
</CardGroup>

## API Health Check

The [API Health Check](/en/monitor/api-health-check) module enables monitoring the uptime status of the Proxy within the specified time interval using the Uptime Monitor. Actions can be triggered when expectations are not met.

<AccordionGroup>
  <Accordion title="Basic Features">
    * **Basic Purpose**: Monitor uptime status and trigger actions
    * **Configuration**: Monitor Name, Description, Active status, and execution frequency (Trigger Every) are determined
    * **Request Information**: Method type and URL of the URL to be tested are entered
    * **Assertions**: Used to validate monitor results
    * **Action**: Selection of the action to be performed when the monitor is executed is provided
  </Accordion>

  <Accordion title="Assertions">
    Used to validate monitor results:

    * **Result Status Code**: Default 200
    * **Result Body**: Response body check
    * **XPath Result**: XML response check
    * **JsonPath Result**: JSON response check
  </Accordion>
</AccordionGroup>

## Anomaly Detector

The [Anomaly Detector](/en/monitor/anomaly-detector) is a technique that enables finding unexpected situations or patterns by analyzing time-based data in log records. In the literature, these unexpected situations are called outliers or exceptions.

<AccordionGroup>
  <Accordion title="Basic Features">
    * **Definition**: Detection of situations (anomalies) that do not conform to expected behaviors of data (e.g., unexpected spending increase)
    * **Data Sources**: Query created/selected to analyze log records and Filter information to be added to it are required
    * **Conditions**: Multiple conditions can be used to determine an anomaly, and these are connected with the 'and' operator
    * **Action**: Selection of the action to be performed when an anomaly is detected is provided
  </Accordion>

  <Accordion title="Metric Measurement Types">
    There are four different types of metric measurements:

    1. **Metric Value Check**: Situations such as whether the average value of the metric is above/below a threshold are checked
    2. **Metric Increase/Decrease Rate Check**: Comparison of the metric's behavior (e.g., increase rate) relative to the previous value is specified
    3. **EMA with Bollinger Bands Usage**: EMA formula is applied on the selected metric value, and it is checked whether the result is above the Upper Bollinger Band value
    4. **Query/Filter Rate Check**: The ratio of the result from the filter and query at runtime to only the result from the filter is expressed as a percentage
  </Accordion>
</AccordionGroup>

## Alarm

The [Alarm](/en/monitor/alarm) module enables adding alarms that will occur when a specific condition is triggered. Alarm works based on a specified Threshold value.

<AccordionGroup>
  <Accordion title="Basic Features">
    * **Basic Purpose**: Create warnings based on specified threshold value
    * **Configuration**: Name, Description, and Threshold value for the alarm are determined
    * **Trigger Type**: Alarm's Trigger Type is selected
    * **Execution Frequency**: Alarm's execution frequency is determined with the Trigger Every field
    * **Actions**: Selection of the action to be performed when the alarm is triggered is provided
  </Accordion>

  <Accordion title="Trigger Types">
    * **Application Logs Count**: Log Type must be selected
    * **Elasticsearch Types**: Connection Definition must be selected
    * **Kubernetes**: Pod and Node health status monitoring
    * **Certificate**: SSL and JWK certificate duration tracking
  </Accordion>
</AccordionGroup>