In this article, we will see how to monitor Oracle backups using Zabbix and the Oracle plugin available with Zabbix Agent 2.

This guide assumes that:

• ARCHIVELOG mode is already enabled,
• RMAN backups are already configured,
• and Zabbix Agent 2 is already installed on the Oracle server.

Setup Zabbix agent 2

By default, the Oracle template provided with Zabbix does not include items dedicated to backup monitoring.
To achieve this, we will use the Oracle plugin feature called CustomQueries. You can find the documentation for this plugin on the official web-site.

The approach is straightforward:

• create custom SQL queries,
• store them locally on the database server,
• and let Zabbix execute them periodically

First, create a directory that will contain your monitoring SQL scripts:

mkdir -p /etc/zabbix/oracle/sql 

chmod 755 -R /etc/zabbix/oracle/sql

Create a SQL script that returns the timestamp of the latest level 0 backup.

vi /etc/zabbix/oracle/sql/last_inc0.sql

SELECT
    CAST(((CAST(BS.COMPLETION_TIME AS DATE) - DATE '1970-01-01') * 86400) AS NUMERIC) AS LAST_INC0
FROM
    V$BACKUP_SET BS
WHERE
    BS.INCREMENTAL_LEVEL = 0
ORDER BY
    BS.COMPLETION_TIME DESC
FETCH FIRST 1 ROWS ONLY;

This query retrieves the completion time of the latest RMAN level 0 backup. Then, it converts the value into Unix epoch format, which makes preprocessing and trigger calculations much easier inside Zabbix.

You can easily adapt this query to monitor:

• archive log backups,
• level 1 incremental backups,
• controlfile backups,
• or even backup duration.

Configure the Oracle Plugin

Now edit the Oracle plugin configuration file:

vi /etc/zabbix/zabbix_agent2.d/plugins.d/oracle.conf

Plugins.Oracle.CustomQueriesPath=/etc/zabbix/oracle/sql/

With this configuration, the Oracle plugin knows exactly where to find your custom SQL scripts.

Afterward, restart the Zabbix Agent 2 service:

systemctl restart zabbix-agent2

Setup Zabbix template

In your Oracle template, create a new Zabbix agent item using the following key:

oracle.custom.query[“{$ORACLE.CONNSTRING}”,”{$ORACLE.USER}”,”{$ORACLE.PASSWORD}”,”{$ORACLE.SERVICE}”,last_inc0]

Make sure that:

• the query name matches your SQL file name (last_inc0.sql),
• and the preprocessing steps are correctly configured.

Once the item becomes active, Zabbix immediately starts collecting the timestamp of the latest level 0 backup.

• And now you can see your last backup time. Then you just have to create a trigger with this item and you have finished !

Conclusion

By using custom Oracle queries with Zabbix Agent 2, you can quickly extend the default Oracle monitoring capabilities with very little configuration effort.

More importantly, this approach helps you detect backup issues early before the FRA fills up and impacts production systems.

Because the solution remains fully customizable, you can easily extend it later to monitor additional RMAN metrics that match your operational requirements.

You can find other blog regarding Zabbix with this link.

L’article Zabbix – Oracle backups monitoring est apparu en premier sur dbi Blog.

Introduction

Within WebLogic 14, out-of-the-box tools such as the Remote Console and WLST scripts provide some visibility, but they are limited when it comes to real-time metrics, historical analysis, or predictive monitoring.

This is where the Elastic Stack (Elasticsearch, Logstash, Beats, Elastic Agent, Kibana, and Elastic Machine Learning) delivers real value. By integrating WebLogic 14 logs, traces and metrics with Elastic Stack, you can build a unified platform that provides:

• Real-time observability of servers, threads, JDBC pools, and JVM health.
• Powerful visualization and analysis in Kibana.
• Predictive monitoring through anomaly detection and forecasting.

In this blog, we’ll walk through the integration of metrics step by step.

Step 1: Export WebLogic 14 Metrics

WebLogic does not natively expose metrics in formats suitable for Elastic or Prometheus. The solution is the WebLogic Monitoring Exporter, which translates JMX metrics into Prometheus-style output.

Download the exporter:

wget https://github.com/oracle/weblogic-monitoring-exporter/releases/download/v2.3.0/weblogic-monitoring-exporter.jar

Configure it (config.yaml):

domains:
  - name: mydomain
    url: t3://localhost:7001
    username: monitoruser
    password: XXXXXXXXXX
    metrics:
      - name: ServerHealth
      - name: ThreadPool
      - name: JDBCConnectionPool
      - name: JVMRuntime

Start the exporter:

java -jar weblogic-monitoring-exporter.jar --config=config.yaml

Verify metrics are exposed at:

http://localhost:8080/metrics

Step 2: Collect Metrics with Metricbeat

Elastic provides Metricbeat with a Prometheus module, making it easy to scrape WebLogic exporter metrics and send them to Elasticsearch.

Enable and configure the module:

metricbeat modules enable prometheus

prometheus.yml configuration:

- module: prometheus
  period: 10s
  hosts: ["http://localhost:8080"]
  metrics_path: /metrics

Start Metricbeat:

sudo metricbeat setup
sudo service metricbeat start

Now WebLogic metrics are flowing into Elasticsearch.

Step 3: Collect WebLogic Logs with Filebeat or Elastic Agent

Metrics give you system health, but logs provide context. To correlate performance issues with application errors, you should ingest WebLogic logs into Elasticsearch.

Option A: Using Filebeat

Install and configure Filebeat on the WebLogic server.

Example configuration (filebeat.yml):

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /u02/app/weblogic/domains/mydomain/servers/*/logs/*.log
    fields:
      application: weblogic
    multiline.pattern: '^\<'
    multiline.negate: true
    multiline.match: after

output.elasticsearch:
  hosts: ["http://localhost:9200"]

And start Filebeat.

Option B: Using Elastic Agent (Recommended)

Elastic Agent simplifies deployment by combining logs, metrics, and security data collection into a single agent managed centrally via Kibana Fleet.

Steps:

1. Enroll the agent from Kibana – Fleet.
2. Attach the System + Custom Log integration.
3. Configure the WebLogic log path.
4. Deploy the agent on your WebLogic server.

This approach reduces operational overhead and centralizes configuration.

Next steps & Conclusion

Next steps:

• Build Observability Dashboards in Kibana
• Add APM for Transaction-Level Visibility
• Enable Machine Learning for Predictive Monitoring
• Configure Alerts

While WebLogic 14 provides essential administrative tooling, it does not offer full observability capabilities out of the box.

By integrating it with the Elastic Stack, you gain:

• Real-time operational insight
• Deep log and metric correlation
• Predictive monitoring with machine learning
• Actionable alerting
• Transaction-level visibility

This approach scales from a single WebLogic instance to enterprise clusters and hybrid cloud deployments.

In short: you move from reactive troubleshooting to proactive performance management.

See my Elastic blogs.

L’article WebLogic 14 & Elastic Stack: From Metrics to Predictive Insights est apparu en premier sur dbi Blog.

Data Stream vs Index

A data stream lets you store append-only time series data across multiple indices while giving you a single named resource for requests. Data streams are well-suited for logs, events, metrics, and other continuously generated data.

You can submit indexing and search requests directly to a data stream. The stream automatically routes the request to backing indices that store the stream’s data.

A data stream consists of one or more hidden, auto-generated backing indices.

This correspond to our use case, so we have a Data Stream “logs-generic-default” and hidden index “.ds-logs-generic-default-2023.10.12-000001“.

Data view

In fact, Kibana requires a data view to access the Elasticsearch data that you want to explore. The data view is based on an index pattern which selects the data to use.

An index pattern can point to one or more indices, data stream, or index aliases. For example, an index pattern can point to your log data from yesterday, or all indices that contain your data.

To create your data view, click on “Create data view” in “Discover”:

Or, follow these steps:

• Open the main menu, then click to Stack Management > Data Views.
• Click Create data view.

Following both ways, the below form appear:

Give a name to the data view, specify the Index pattern which match with the index or indices. Then click on “Save data view to Kibana”.

The view could be updated or deleted at any time:

Go back to “Discover”, the view we created is selected by default as it is the only one:

No results match our search criteria, because we are looking for entries in last 15 minutes only. Update the time filter on the top right. and put 15 hours instead:

Now we have data:

As explained in the previous blog, each line in the log file is considered as a separate entry by Filebeat. In Elasticsearch an entry is a document, which is a json object.

Let’s explore the first document in json:

{
  "_index": ".ds-logs-generic-default-2023.10.12-000001",
  "_id": "MDYEJIsBhUUDY9jEKY1i",
  "_version": 1,
  "_score": 0,
  "_source": {
    "input": {
      "type": "log"
    },
    "agent": {
      "name": "vmelastic",
      "id": "b9b7d708-be91-4bb9-b2f4-7910e65a6be4",
      "type": "filebeat",
      "ephemeral_id": "2cad7906-53bc-4a79-a83b-6d7977e239d8",
      "version": "8.10.2"
    },
    "@timestamp": "2023-10-12T13:12:13.305Z",
    "ecs": {
      "version": "8.0.0"
    },
    "log": {
      "file": {
        "path": "/var/log/elasticsearch/elasticsearch.log"
      },
      "offset": 32657
    },
    "data_stream": {
      "namespace": "default",
      "type": "logs",
      "dataset": "generic"
    },
    ...
    "@version": "1",
    "message": "[2023-10-12T15:12:12,217][INFO ][o.e.c.m.MetadataCreateIndexService] [vmelastic] [.ds-logs-generic-default-2023.10.12-000001] creating index, cause [initialize_data_stream], templates [logs], shards [1]/[1]",
...

Search

Your huge volumes of data is searchable in near real time!

Let’s search for “generic”:

At the end of this use case, I let you imagine all your data (metrics, log files, business data, etc) centralized in Elasticsearch. All your data are searchable and analyzed in near real time. Enjoy

L’article Logs from Filebeat to Logstash to Elasticsearch – 3 est apparu en premier sur dbi Blog.

Configure Filebeat

First of all, let’s understand how Filebeat works.

We have to configure inputs and outputs, once Filebeat starts it looks in the locations we specified and start a harvester for each log file found. Harvesters send log data to libbeat, which send data to the output(s) defined.

Each new line in the log file detected is considered as new entry.

As you can see in the below, many inputs and outputs could be defined.

In our use case we will send the data from Filebeat to Logstash. For that we will need to update the filebeat.yml. In the inputs section, add an input to push Elasticsearch logs.

# ============================== Filebeat inputs ===============================

filebeat.inputs:
- type: log
  paths:
    - /var/log/elasticsearch/elasticsearch.log
  multiline.pattern: '^\[[0-9]{4}-[0-9]{2}-[0-9]{2}'
  multiline.negate: true
  multiline.match: after

What multiline configuration mean?

The file harvested by Filebeat may contain messages that span multiple lines of text. For example, multiline messages are common in files that contain Java stack traces. In order to correctly handle these multiline events configure a pattern, and so Filebeat group all the lines in one entry which make more sense!

Still in filebeat.yml file, in the outputs section:

# ------------------------------ Logstash Output -------------------------------
output.logstash:
  # The Logstash hosts
  hosts: ["localhost:5044"]

Don’t start Filebeat before Logstash is configured and ready.

Configure Logstash

Filebeat is able to send data directly to Elasticsearch, but in some use cases we need to filter or transform data, so Logstash is needed. I will publish a dedicated blog showing how to filter/transform data using Logstash, that’s why this will not be covered in this blog.

Create a configuration file in config folder, containing input and output:

input {
  beats {
    port => 5044
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
  }
}

This means that data will be received from beats, and should be sent to Elasticsearch.

Here Filebeat, Logstash and Elasticsearch have been installed on the same server, if it is not your case the only change to do is on hosts value!

Start Logstash pointing to the config file just created, e.g.:

$LOGSTASH_HOME/bin/logstash -f $LOGSTASH_HOME/config/beats.conf

Logstash log should look like:

[2023-10-12T14:50:39,856][INFO ][org.logstash.beats.Server][main][07404911f6955878a51e8dfe9c8b1b8d65de08b278ae40b3521288a61a3e6ec6] Starting server on port: 5044
[2023-10-12T14:50:39,941][INFO ][logstash.agent           ] Pipelines running {:count=>1, :running_pipelines=>[:main], :non_running_pipelines=>[]}

Remember, we didn’t start Filebeat so no data has been sent to Logstash yet.

Configure Elasticsearch

At this stage, Elasticsearch and Logstash are already running, no data received yet!

Check “Discover” on Kibana show that there is no data.

Start filebeat:

$FILEBEAT_HOME/filebeat -e

Check again the “Discover” on Kibana:

We have data in Elasticsearch now!

In the next blog, I will share how to configure Kibana to discover the data stored in Elasticsearch.

L’article Logs from Filebeat to Logstash to Elasticsearch – 2 est apparu en premier sur dbi Blog.

Let’s start by the first step, which is the installation of all components (Filebeat, Logstash, Elasticsearch, and Kibana). For that I will use an environment with 3 VMs as following:

Filebeat Installation

Let’s install Filebeat on the server we want to monitor (vmelastic1).

To download and install Filebeat, you can use tar package (other options are available here):

[elastic@vmelastic1 app]# curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.8.1-linux-x86_64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 41.3M  100 41.3M    0     0   317k      0  0:02:13  0:02:13 --:--:-- 8579k
[elastic@vmelastic1 app]# tar xzvf filebeat-8.8.1-linux-x86_64.tar.gz
filebeat-8.8.1-linux-x86_64/filebeat
filebeat-8.8.1-linux-x86_64/fields.yml
...
[elastic@vmelastic1 app]# ls -rtl filebeat-8.8.1-linux-x86_64
total 140532
-rw-r--r--  1 elastic elastic   2647144 Jun  5 21:56 NOTICE.txt
-rw-r--r--  1 elastic elastic     13675 Jun  5 21:56 LICENSE.txt
drwxr-xr-x  4 elastic elastic        24 Jun  5 22:26 kibana
-rw-------  1 elastic elastic      8622 Jun  5 22:26 filebeat.yml
-rw-r--r--  1 elastic elastic    177676 Jun  5 22:26 filebeat.reference.yml
-rw-r--r--  1 elastic elastic   3745648 Jun  5 22:26 fields.yml
drwxr-xr-x  2 elastic elastic      4096 Jun  5 22:26 modules.d
drwxr-xr-x 71 elastic elastic      4096 Jun  5 22:26 module
-rwxr-xr-x  1 elastic elastic 137281944 Jun  5 22:36 filebeat
-rw-r--r--  1 elastic elastic       809 Jun  5 22:36 README.md

We will configure Filebeat in a next step.

Logstash Installation

Now, we will install Logstash on a separate server (vmelastic2).

To download and install Logstash, you can use tar package (other options are available here):

[elastic@vmelastic2 app]# curl -L -O https://artifacts.elastic.co/downloads/logstash/logstash-8.8.1-linux-x86_64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  327M  100  327M    0     0  2399k      0  0:02:19  0:02:19 --:--:-- 25.8M
[elastic@vmelastic2 app]# tar xvf logstash-8.8.1-linux-x86_64.tar.gz
...
logstash-8.8.1/jdk/release
logstash-8.8.1/LICENSE.txt
logstash-8.8.1/logstash-core/lib/logstash/build.rb
[elastic@vmelastic2 app]# ls -rtl logstash-8.8.1
total 664
-rw-r--r-- 1 elastic wheel 606491 Jun  2 19:42 NOTICE.TXT
-rw-r--r-- 1 elastic wheel  13675 Jun  2 19:42 LICENSE.txt
-rw-r--r-- 1 elastic wheel     16 Jun  2 19:42 JDK_VERSION
-rw-r--r-- 1 elastic wheel  30037 Jun  2 19:42 Gemfile.lock
-rw-r--r-- 1 elastic wheel   4101 Jun  2 19:42 Gemfile
drwxr-xr-x 2 elastic wheel      6 Jun  2 19:42 data
-rw-r--r-- 1 elastic wheel   2276 Jun  2 19:42 CONTRIBUTORS
drwxr-xr-x 2 elastic elastic    4096 Jun 27 15:34 bin
drwxr-xr-x 2 elastic elastic     142 Jun 27 15:34 config
drwxr-xr-x 4 elastic elastic      55 Jun 27 15:34 modules
drwxr-xr-x 6 elastic elastic      84 Jun 27 15:34 lib
drwxr-xr-x 3 elastic elastic      30 Jun 27 15:34 tools
drwxr-xr-x 3 elastic elastic      86 Jun 27 15:34 logstash-core-plugin-api
drwxr-xr-x 4 elastic elastic      90 Jun 27 15:34 logstash-core
drwxr-xr-x 4 elastic elastic      33 Jun 27 15:34 vendor
drwxr-xr-x 9 elastic elastic     193 Jun 27 15:34 x-pack
drwxr-xr-x 9 elastic elastic     121 Jun 27 15:35 jdk

Logstash configuration will be done later.

Elasticsearch Installation

It is time to install Elasticsearch on a separate server (vmelastic3).

To download and install Elasticsearch, you can use tar package (other options are available here):

[elastic@vmelastic3 app]# curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.8.1-linux-x86_64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  569M  100  569M    0     0  3927k      0  0:02:28  0:02:28 --:--:-- 27.7M
[elastic@vmelastic3 app]# tar xvf elasticsearch-8.8.1-linux-x86_64.tar.gz
elasticsearch-8.8.1/
elasticsearch-8.8.1/lib/
...
[elastic@vmelastic3 app]# ls -rtl elasticsearch-8.8.1/
total 2224
-rw-r--r--  1 elastic elastic    8106 Jun  5 23:31 README.asciidoc
-rw-r--r--  1 elastic elastic    3860 Jun  5 23:31 LICENSE.txt
drwxr-xr-x  2 elastic elastic       6 Jun  5 23:33 plugins
drwxr-xr-x  2 elastic elastic       6 Jun  5 23:33 logs
-rw-r--r--  1 elastic elastic 2251526 Jun  5 23:33 NOTICE.txt
drwxr-xr-x  5 elastic elastic    4096 Jun  5 23:37 lib
drwxr-xr-x  8 elastic elastic      96 Jun  5 23:37 jdk
drwxr-xr-x  2 elastic elastic    4096 Jun  5 23:37 bin
drwxr-xr-x 74 elastic elastic    4096 Jun  5 23:37 modules
drwxr-xr-x  3 elastic elastic     210 Jun 27 16:05 config

Elasticsearch configuration will be done later.

Kibana Installation

The last one is Kibana, will be installed on the same server as Elasticsearch (vmelastic3).

To download and install Elasticsearch, you can use tar package (other options are available here):

[elastic@vmelastic3 app]# curl -L -O https://artifacts.elastic.co/downloads/kibana/kibana-8.8.1-linux-x86_64.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  263M  100  263M    0     0  1705k      0  0:02:38  0:02:38 --:--:-- 7537k
kibana-8.8.1/x-pack/plugins/fleet/target/
kibana-8.8.1/x-pack/plugins/fleet/target/agent_versions_list.json
[elastic@vmelastic3 app]# ls -rtl kibana-8.8.1
total 1388
drwxr-xr-x   4 elastic elastic      95 Jun  6 00:19 x-pack
drwxr-xr-x  11 elastic elastic     191 Jun  6 00:19 src
-rw-r--r--   1 elastic elastic    3966 Jun  6 00:19 README.txt
drwxr-xr-x   2 elastic elastic       6 Jun  6 00:19 plugins
drwxr-xr-x   5 elastic elastic      52 Jun  6 00:19 packages
-rw-r--r--   1 elastic elastic     738 Jun  6 00:19 package.json
-rw-r--r--   1 elastic elastic 1370699 Jun  6 00:19 NOTICE.txt
drwxr-xr-x 693 elastic elastic   20480 Jun  6 00:19 node_modules
drwxr-xr-x   2 elastic elastic       6 Jun  6 00:19 logs
-rw-r--r--   1 elastic elastic    3860 Jun  6 00:19 LICENSE.txt
drwxr-xr-x   2 elastic elastic       6 Jun  6 00:19 data
drwxr-xr-x   2 elastic elastic      44 Jun  6 00:19 config
drwxr-xr-x   6 elastic elastic      71 Jun  6 00:19 node
drwxr-xr-x   2 elastic elastic     175 Jun  6 00:19 bin

Next steps

In a next blog, I will configure all these components to push logs from Filebeat to Logstash, make some transformation in Logstash, then send data to Elasticsearch, and see data from Kibana.

Stay connected 😉

L’article Logs from Filebeat to Logstash to Elasticsearch -1 est apparu en premier sur dbi Blog.

Introduction

Are you using ELK for logging? In fact, both Filebeat and Logstash can be used to send logs from a file-based data source to a supported output destination. In most cases, we will be using both in tandem when building a logging pipeline with the ELK Stack because both have a different function, that’s what we will discover together.

So, why compare both products?

Well, people are getting confused by the differences between the two log shippers. With the introduction of Beats, the growth in both their popularity, and the number of use cases, people are inquiring whether the two are complementary or mutually exclusive!

This blog will attempt to shed some light on what makes these two tools both alternatives to each other and complementary at the same time

What is Logstash?

Logstash was originally developed by Jordan Sissel to handle the streaming of a large amount of log data from multiple sources, and after Sissel joined the Elastic team, Logstash evolved from a standalone tool to an integral part of the ELK Stack (Elasticsearch, Logstash, Kibana).

Logstash advantages

Logstash is an effective centralized logging system, a tool that handle the tasks of pulling and receiving the data from multiple systems, transforming it into a meaningful set of fields and eventually streaming the output to a defined destination for storage.

This sounds cool and enough, so why Filebeat exists? Let’s see the disadvantages

Logstash disadvantages

Even if Logstash was and still great, there is one outstanding issue, it is performance! Yes, Logstash requires JVM to run, and this dependency coupled with the implementation in Ruby became the root cause of significant memory consumption…

As necessity is the mother of invention… Beats are here

What is Filebeat?

The different Beats are used as lightweight agents installed on the different servers in the infrastructure for shipping logs or metrics. These can be log files (Filebeat), network metrics (Packetbeat), server metrics (Metricbeat), or any other type of data that can be collected by the growing number of Beats being developed by both Elastic and the community.

Filebeat advantages

Filebeat is just a tiny binary with no dependencies, it takes very little resources. That said, you have lots of knobs regarding what it can do. For example, how aggressive it should be in searching for new files to tail and when to close file handles when a file didn’t get changes for a while.

To help you get started, Filebeat comes with modules for specific log types. For example, the Apache module will point Filebeat to default access.log and error.log paths. Personally, I always configure logs entry.

Filebeat disadvantages

Filebeat’s scope is very limited, so you’ll have a problem to solve somewhere else. For example, if you use Logstash down the pipeline, you have about the same performance issue. Because of this, Filebeat’s scope is growing. Initially it could only send logs to Logstash and Elasticsearch, but now it can send to Kafka and Redis. Filebeat can also do some filtering: it can drop events or append metadata to them.

So, what shall I use, Logstash or Filebeat?

Before answering this question, let’s say that Logstash is rarely implemented in modern implementations of the ELK Stack, I do not recommend using Logstash for log processing only, its too heavy and burdensome.

On the other hand, Filebeat is one of the best log file shippers out there today, it’s lightweight, supports SSL and TLS encryption, supports back pressure with a good built-in recovery mechanism, and is extremely reliable. It cannot, however, in most cases, turn your logs into easy-to-analyze structured log messages using filters for log enhancements. That’s the role played by Logstash.

You got it, it depends on your use case

If you are interested only in the timestamp and message fields to push them to Elasticsearch, I would say, use Filebeat for sure! If you want more, I mean if you want transformation, Logstash could play this role.

L’article ELK Stack – Filebeat vs Logstash est apparu en premier sur dbi Blog.

Snapshot lifecycle management (SLM) is the easiest way to regularly back up a cluster. An SLM policy automatically takes snapshots on a preset schedule. The policy can also delete snapshots based on retention rules you define.

Please note that Elasticsearch Service deployments automatically include the cloud-snapshot-policy SLM policy. Elasticsearch Service uses this policy to take periodic snapshots of your cluster.

SLM security

The following cluster privileges control access to the SLM actions when Elasticsearch security features are enabled:

• manage_slm : Allows a user to perform all SLM actions, including creating and updating policies and starting and stopping SLM.
• read_slm : Allows a user to perform all read-only SLM actions, such as getting policies and checking the SLM status.
• cluster:admin/snapshot/* : Allows a user to take and delete snapshots of any index, whether or not they have access to that index.

You can create and manage roles to assign these privileges through Kibana Management.

To grant the privileges necessary to create and manage SLM policies and snapshots, you can set up a role with the manage_slm and cluster:admin/snapshot/* cluster privileges and full access to the SLM history indices.

For example, the following request creates an slm-admin role:

POST _security/role/slm-admin
{
  "cluster": [ "manage_slm", "cluster:admin/snapshot/*" ],
  "indices": [
    {
      "names": [ ".slm-history-*" ],
      "privileges": [ "all" ]
    }
  ]
}

To grant read-only access to SLM policies and the snapshot history, you can set up a role with the read_slm cluster privilege and read access to the snapshot lifecycle management history indices.

For example, the following request creates a slm-read-only role:

POST _security/role/slm-read-only
{
  "cluster": [ "read_slm" ],
  "indices": [
    {
      "names": [ ".slm-history-*" ],
      "privileges": [ "read" ]
    }
  ]
}

Create an SLM policy

To manage SLM in Kibana, go to the main menu and click Stack Management > Snapshot and Restore > Policies. To create a policy, click Create policy.

You can also manage SLM using the SLM APIs. To create a policy, use the create SLM policy API.

The following request creates a policy that backs up the cluster state, all data streams, and all indices daily at 1:30 a.m. UTC

PUT _slm/policy/nightly-snapshots
{
  "schedule": "0 30 1 * * ?",       
  "name": "<nightly-snap-{now/d}>", 
  "repository": "my_repository",    
  "config": {
    "indices": "*",                 
    "include_global_state": true    
  },
  "retention": {                    
    "expire_after": "30d",
    "min_count": 5,
    "max_count": 50
  }
}

• schedule: When to take snapshots, written in Cron syntax.
• name: Supports date math. To prevent naming conflicts, the policy also appends a UUID to each snapshot name.
• repository: Registered snapshot repository used to store the policy’s snapshots.
• config: Data streams and indices to include in the policy’s snapshots.
• include_global_state: If true, the policy’s snapshots include the cluster state.
• retention: This configuration keeps snapshots for 30 days, retaining at least 5 and no more than 50 snapshots regardless of age.

Manually run an SLM policy

You can manually run an SLM policy to immediately create a snapshot. This is useful for testing a new policy or taking a snapshot before an upgrade. Manually running a policy doesn’t affect its snapshot schedule.

To run a policy in Kibana, go to the Policies page and click the run icon under the Actions column.

You can also use the execute SLM policy API.

POST _slm/policy/nightly-snapshots/_execute

Please note that the snapshot process runs in the background. To monitor any currently running snapshots, use the get snapshot API with the _current request path parameter.

GET _snapshot/my_repository/_current

SLM Retention

SLM snapshot retention is a cluster-level task that runs separately from a policy’s snapshot schedule. To control when the SLM retention task runs, configure the slm.retention_schedule cluster setting.

PUT _cluster/settings
{
  "persistent" : {
    "slm.retention_schedule" : "0 30 1 * * ?"
  }
}

To immediately run the retention task, execute:

POST _slm/_execute_retention

Please note that an SLM policy’s retention rules only apply to snapshots created using the policy. Other snapshots don’t count toward the policy’s retention limits.

These are the most important points to know about SLM, you know how to create, configure, execute, secure SLM. This is very helpful feature I hope this blog will be helpful, if you have any question, don’t hesitate to ask 🙂

L’article Elasticsearch – Snapshot Lifecycle Management (SLM) est apparu en premier sur dbi Blog.

A snapshot is a backup of a running Elasticsearch cluster, it could be used to:

• Regularly back up a cluster with no downtime
• Recover data after deletion or a hardware failure
• Transfer data between clusters
• Reduce your storage costs by using searchable snapshots in the cold and frozen data tiers.

Please note that this blog has been written based on Elasticsearch version 8.8. The snapshot and restore methodology would different from an older version.

Snapshot repository

Elasticsearch stores snapshots in an off-cluster storage location called a snapshot repository. Before you can take or restore snapshots, you must register a snapshot repository on the cluster. Elasticsearch supports several repository types with cloud storage options, including: AWS S3, Google Cloud Storage (GCS), and Microsoft Azure.

To register a repository, it is so easy with new Elasticsearch versions, it could be done from Stack Management. As you can see below, you can choose from Azure, Google, or AWS.

Snapshot contents

By default, a snapshot of a cluster contains the cluster state, all regular data streams, and all regular indices. In fact, the cluster state includes:

• Persistent cluster settings
• Index templates
• Legacy index templates
• Ingest pipelines
• ILM policies

Please note that you can also take snapshots of only specific data streams or indices in the cluster.

In all cases, snapshots don’t contain or back up:

• Transient cluster settings
• Registered snapshot repositories
• Node configuration files
• Security configuration files

Manually take a snapshot

You can use the create snapshot API to create snapshot manually, Depending on its size, a snapshot can take a while to complete. By default, the create snapshot API only initiates the snapshot process, which runs in the background. To block the client until the snapshot finishes, set the wait_for_completion query parameter to true.

Snapshot Lifecycle Management (SLM)

Snapshot lifecycle management (SLM) is the easiest way to regularly back up a cluster. An SLM policy automatically takes snapshots on a preset schedule. The policy can also delete snapshots based on retention rules you define.

To keep this blog readable, we will talk about SLM in a dedicated blog

Snapshot compatibility

I already mentioned that in a previous blog, let’s talk about quickly here as it is a very critical topic.

In fact, any index you restore from a snapshot must also be compatible with the current cluster’s version. So, if you try to restore an index created in an incompatible version, the restore attempt will fail.

Please find below the compatibility between index creation version and the cluster version:

Please note that we are talking about “Index creation version” and not “snapshot creation version”, which means that if you take a snapshot with version 6.8 of an index created in 5.6. The snapshot will not be compatible with 7.1! So, please be careful

Restore a snapshot

By default, a restore request attempts to restore all regular indices and regular data streams in a snapshot. In most cases, you only need to restore a specific index or data stream from a snapshot. However, you can’t restore an existing open index!

If it is your case, you can use one of the following methods to avoid conflicts with existing indices and data streams:

Delete and Restore
The simplest way to avoid conflicts is to delete an existing index or data stream before restoring it. To prevent the accidental re-creation of the index or data stream, I recommend you temporarily stop all indexing until the restore operation is complete.

# Delete an index
DELETE my-index

# Restore the index
POST _snapshot/my_repository/my_snapshot_2023.06.22/_restore
{
  "indices": "my-index"
}

Rename on restore

If you want to avoid deleting existing data, you can instead rename the indices and data streams you restore. You typically use this method to compare existing data to historical data from a snapshot. For example, you can use this method to review documents after an accidental update or deletion.

Before you start, ensure the cluster has enough capacity for both the existing and restored data!

POST _snapshot/my_repository/my_snapshot_2023.06.22/_restore
{
  "indices": "my-index",
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1"
}

Stay connected for the next blog about SLM, in the meantime, please don’t hesitate to ask question or share your experience with Snapshot and Restore.

L’article Elasticsearch – Snapshot and Restore est apparu en premier sur dbi Blog.