Troubleshooting — Kibana

Overview

Kibana is the web-based UI for Elasticsearch. For Diskover, its primary use is Index Lifecycle Management (ILM) — defining advanced policies that automatically manage the retention and deletion of Diskover indices over time.

Note: Diskover v2.4.2 and later includes an ILM tool directly in Diskover Admin > Indices. We recommend using the Diskover Admin UI for lightweight integrated Index Lifecycle Management, and fall back to Kibana for advanced configuration not exposed in the Diskover UI.

Kibana is optional. It is not required for Diskover to function, but is useful for operators who need direct visibility into Elasticsearch or need to configure advanced ILM policies manually.

Service Management

# Start
sudo systemctl start kibana

# Stop
sudo systemctl stop kibana

# Restart
sudo systemctl restart kibana

# Status
sudo systemctl status kibana

# Enable on boot
sudo systemctl enable kibana

Kibana runs on port 5601 by default. Access at http://<host>:5601.

Index Lifecycle Management (ILM)

What Is ILM?

ILM policies define rules for automatically transitioning or deleting Elasticsearch indices based on age or size. For Diskover, this is primarily used to automatically remove old crawl indices that are no longer needed, keeping the cluster from growing unbounded.

A typical Diskover ILM policy will define a delete phase — for example, delete any index older than 90 days.

Managing ILM in Diskover Admin (v2.4.2+)

In Diskover v2.4.2 and later, ILM policies can be created and applied directly from Diskover Admin > Indices > ILM Policies. This is the recommended approach for most use cases.

From the Diskover Admin ILM tool you can:

Create and apply an ILM policy to Diskover indices
Set a retention period (delete phase) for automatic index cleanup
View the current ILM policy applied to each index

Managing ILM in Kibana

For advanced ILM configuration not available in the Diskover Admin UI, use Kibana:

Stack Management > Index Lifecycle Policies

From here you can:

Create and edit ILM policies with full phase control (hot, warm, cold, delete)
Apply policies to existing Diskover indices
View phase transition status for each index

Applying a Policy to Existing Indices

To manually apply an ILM policy to a Diskover index from Kibana:

Go to Stack Management > Index Management
Select the index
Click Manage index > Add lifecycle policy
Select the policy and confirm

Checking ILM Status

To view the current lifecycle phase and any errors for Diskover indices:

Go to Stack Management > Index Management
Filter by diskover- to list all Diskover indices
The Lifecycle phase column shows the current state

Or query directly:

curl -s "http://localhost:9200/diskover-*/_ilm/explain?pretty"

Advanced ILM: Data Tiering and Archival

The Diskover Admin ILM tool is designed for delete-only policies. For environments where older indices need to be archived rather than deleted — moved to cheaper or slower storage tiers while remaining queryable — ILM policies must be configured directly in Kibana.

Data Tiers Overview

Elasticsearch supports four data tiers. Nodes are assigned to a tier via the node.roles setting in elasticsearch.yml:

Tier	Role	Typical Use
Hot	`data_hot`	Active indices; full read/write performance
Warm	`data_warm`	Recent but inactive indices; reduced resources
Cold	`data_cold`	Older indices; infrequent access, read-only
Frozen	`data_frozen`	Long-term archive; indices partially unmounted from memory

For a single-node cluster, all tiers map to the same node and tiering has no physical effect. Tiering is most valuable in multi-node clusters where nodes are provisioned with different hardware (e.g., SSD hot nodes, HDD cold nodes).

Example: Hot → Warm → Cold → Delete Policy

This policy transitions Diskover indices through tiers based on age, then deletes them after one year. Adjust the min_age values to fit your retention requirements.

PUT _ilm/policy/diskover-tiered-retention
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "set_priority": {
            "priority": 50
          },
          "readonly": {}
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "set_priority": {
            "priority": 0
          },
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "365d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

What this does:

Hot (day 0–30): Index is active and fully writable with high priority for cache retention
Warm (day 30–90): Index becomes read-only and drops in cache priority; still fully searchable
Cold (day 90–365): Index is frozen — Elasticsearch reduces its memory footprint; it remains searchable but queries will be slower
Delete (day 365+): Index is permanently removed

Applying the Policy to Diskover Indices

After creating the policy, apply it to existing Diskover indices:

curl -X PUT "http://localhost:9200/diskover-*/_settings" \
  -H 'Content-Type: application/json' \
  -d '{"index.lifecycle.name": "diskover-tiered-retention"}'

To apply it automatically to all future Diskover indices, attach the policy to an index template. In Kibana: Stack Management > Index Management > Index Templates, then edit or create the diskover template and add the ILM policy under Index settings.

Freeze Considerations

The freeze action (cold phase) significantly reduces heap memory usage for inactive indices by closing their field data caches. The trade-off is slower search response times on frozen indices. If Diskover users are still actively searching older indices, consider skipping the freeze action or extending the cold phase min_age.

Note: The freeze action was deprecated in Elasticsearch 8.x in favour of the frozen tier (data_frozen node role) with searchable snapshots. For ES 8.x clusters, replace the freeze action with a searchable snapshot action if long-term archival is required.