Elastic Stack opbouwen: Operationele gids voor Rocky Linux 9, TLS en ILM

AI_Manager

Dit is een gids voor het opbouwen van de Elastic Stack. Dit proces eindigt niet bij het installeren van vier pakketten. Het moet worden ontworpen als één operationele eenheid, inclusief authenticatie in de verzamelingsfase, TLS en rechten in Elasticsearch, de toegankelijkheid van Kibana, retentiebeleid en snapshot-herstel. Dit artikel beschrijft de reproduceerbare installatie- en verificatieprocedures op basis van Rocky Linux 9 en Elastic Stack 9.4.2.

Hoewel de oefening begint op een enkele host, scheidt een productieomgeving rollen en storingsdomeinen. Bovendien wordt bij elk commando het doel en de verificatiemethode uitgelegd. Wachtwoorden en API-sleutels worden niet hardcoded in de tekst of shell-geschiedenis, en de standaardbeveiligingsinstellingen van Elastic worden niet uitgeschakeld.

Reikwijdte en componenten van de Elastic Stack-opbouw

In dit artikel verwijst ELK naar de historische combinatie van Elasticsearch, Logstash en Kibana, terwijl Elastic Stack staat voor de operationele eenheid inclusief Beats, Agent, beveiliging, levenscyclusbeheer en back-ups. Voor eenvoudige gegevensverzameling kan Logstash worden weggelaten en kunnen Agent of Filebeat direct naar Elasticsearch verzenden.

Ontwerp en vereisten vóór de implementatie van Elastic Stack

Rocky Linux 9 is een RHEL-compatibele distributie, maar als commerciële ondersteuning vereist is, moet de exacte OS-combinatie worden gecontroleerd in de Elastic-ondersteuningsmatrix. Zorg er bovendien voor dat alle Elastic Stack-componenten dezelfde versie hebben. De voorbeelden in dit artikel zijn gebaseerd op versie 9.4.2. Dit betekent niet dat dit de nieuwste versie is; controleer bij installatie de beschikbaarheid van pakketten in de officiële repository en de ondersteuningsmatrix.

Onderscheid tussen praktijk- en productietopologie

Controleer hostbronnen en tijdsynchronisatie

sudo dnf install -y curl jq

cat /etc/rocky-release
uname -r
timedatectl status
free -h
df -hT /var/lib /var/log
sysctl vm.max_map_count
ulimit -n

Elasticsearch gebruikt niet alleen de JVM-heap, maar ook actief de filesystem cache. Daarom kan het combineren van zware Logstash-taken op dezelfde host gemakkelijk leiden tot geheugenconflicten. Gebruik eerst de standaard automatische heap-sizing en pas Xms en Xmx pas aan naar dezelfde waarde als er onderbouwing is vanuit belastingstests.

Elastic Stack implementatie: 9.4.2 repository en pakketinstallatie

Het Elastic Stack-installatiepakket gebruikt de officiële GPG-sleutel en de 9.x RPM-repository. Door de repository standaard uitgeschakeld te laten, verkleint u de kans dat onverwachte grote wijzigingen worden meegenomen tijdens een reguliere dnf update. Controleer wijzigingslogboeken en compatibiliteit vóór installatie.

Officiële GPG-sleutel en repositoryregistratie

sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

sudo tee /etc/yum.repos.d/elastic-9.x.repo >/dev/null <<'EOF'
[elastic-9.x]
name=Elastic repository for 9.x packages
baseurl=https://artifacts.elastic.co/packages/9.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
type=rpm-md
EOF

sudo dnf clean metadata
sudo dnf --disablerepo='*' --enablerepo=elastic-9.x list available   elasticsearch kibana logstash filebeat

Installeer met dezelfde versie en bevestig de vergrendeling

STACK_VERSION='9.4.2'
sudo dnf install --enablerepo=elastic-9.x   "elasticsearch-${STACK_VERSION}"   "kibana-${STACK_VERSION}"   "logstash-${STACK_VERSION}"   "filebeat-${STACK_VERSION}"

rpm -q elasticsearch kibana logstash filebeat
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add elasticsearch kibana logstash filebeat

Als de dnf versionlock-plugin niet aanwezig is, installeer dan eerst python3-dnf-plugin-versionlock. Versievergrendeling betekent niet dat patches permanent moeten worden uitgesteld. Het is een veiligheidsmaatregel om upgrades expliciet uit te voeren tijdens onderhoudsvensters nadat snapshots, compatibiliteit en rollbacks zijn gevalideerd.

Elastic Stack implementatie: Beveiligingsconfiguratie voor Elasticsearch single-node

Bij de praktijkoefening voor een single-node Elastic Stack-implementatie binden we Elasticsearch alleen aan de loopback. De eerste start van Elastic 9.x configureert automatisch authenticatie en TLS voor HTTP en transport. In plaats van dit uit te schakelen, configureren we elke client om de gegenereerde CA te vertrouwen.

Minimale configuratie voor elasticsearch.yml voor praktijkgebruik

Maak een back-up van de bestanden en bewerk ze met de onderstaande opdrachten. Stel de volgende YAML-sleutels elk slechts één keer in het bestaande bestand in en behoud de automatisch gegenereerde authenticatie- en TLS-instellingen. Vervang niet het volledige bestand door deze korte YAML.

sudo cp -a /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.before-lab
sudoedit /etc/elasticsearch/elasticsearch.yml

cluster.name: logs-lab
node.name: es01
network.host: 127.0.0.1
http.host: 127.0.0.1
transport.host: 127.0.0.1
discovery.type: single-node

sudo systemctl daemon-reload
sudo systemctl enable --now elasticsearch
sudo systemctl status elasticsearch --no-pager

Als dezelfde sleutel al in het configuratiebestand staat, voeg deze dan niet dubbel toe, maar wijzig de bestaande waarde. Schakel bij een mislukte start van de service de beveiligingsfuncties niet uit, maar controleer eerst de journal- en Elasticsearch-logs op bootstrap-checks, machtigingen en YAML-fouten.

sudo journalctl -u elasticsearch --since '-10 min' --no-pager
sudo tail -n 100 /var/log/elasticsearch/logs-lab.log
sudo ss -lntp | grep -E ':(9200|9300)\b'

Wachtwoordreset en CA-gebaseerde HTTPS-verificatie

Kopieer alleen het openbare CA-certificaat naar een apart pad zodat curl dit in een normale shell kan lezen. Kopieer niet de CA-privésleutel of de transport/http-keystore.

sudo install -d -m 0755 /etc/elastic-client
sudo install -o root -g root -m 0644 /etc/elasticsearch/certs/http_ca.crt /etc/elastic-client/http_ca.crt
openssl x509 -in /etc/elastic-client/http_ca.crt -noout -fingerprint -sha256

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password   -u elastic -i

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo
export ELASTIC_PASSWORD

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   https://127.0.0.1:9200/ | jq .

unset ELASTIC_PASSWORD

Als u de certificaatverificatie omzeilt, wordt de verbinding weliswaar tot stand gebracht, maar kunt u vervalste servers niet onderscheiden. Distribueer de vingerafdruk van de automatisch gegenereerde CA of het CA-bestand en gebruik per service accounts met minimale rechten of API-sleutels in plaats van persoonlijke wachtwoorden.

Elastic Stack opbouwen: Kibana-registratie en HTTPS-publicatie

Kibana kan worden geregistreerd door de CA en authenticatiegegevens van Elasticsearch te ontvangen via een enrollment token. Het is eenvoudiger om poort 5601 niet direct aan de browser bloot te stellen, maar deze aan 127.0.0.1 te binden en HTTPS te beëindigen via een reverse proxy die gebruikmaakt van organisatiecertificaten.

Kibana enrollment token genereren en registreren

sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token   -s kibana

# Voer het kortlevende token uit de uitvoer van het vorige commando in bij het volgende commando.
sudo /usr/share/kibana/bin/kibana-setup   --enrollment-token '<ONE_TIME_ENROLLMENT_TOKEN>'

sudo tee -a /etc/kibana/kibana.yml >/dev/null <<'EOF'
server.host: "127.0.0.1"
server.port: 5601
server.publicBaseUrl: "https://kibana.example.com"
EOF

sudo systemctl enable --now kibana
sudo journalctl -u kibana --since '-10 min' --no-pager

De domeinen, certificaatpaden en toegestane bereiken in het voorbeeld moeten worden vervangen door de werkelijke waarden. Omdat een enrollment token slechts korte tijd geldig is, moet u dit niet opslaan in documenten of tickets; genereer een nieuw token als het is blootgesteld of verlopen.

Voorbeeld van Nginx HTTPS reverse proxy

Plaats eerst het certificaat en de privésleutel die bij het domein horen op de aangegeven paden en sla het onderstaande serverblok op in /etc/nginx/conf.d/kibana.conf. Controleer ook of het http-blok van de standaard nginx.conf dit directory include.

sudo dnf install -y nginx policycoreutils-utils
sudoedit /etc/nginx/conf.d/kibana.conf
# Sta toe dat Nginx verbinding maakt met Kibana op de loopback onder SELinux enforcing.
sudo setsebool -P httpd_can_network_connect on

server {
    listen 443 ssl http2;
    server_name kibana.example.com;

    ssl_certificate     /etc/pki/tls/certs/kibana-fullchain.pem;
    ssl_certificate_key /etc/pki/tls/private/kibana.key;

    location / {
        proxy_pass http://127.0.0.1:5601;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginx

# Vervang dit door het beheernetwerkadresbereik.
sudo firewall-cmd --permanent --new-zone=kibana-admin || true
sudo firewall-cmd --permanent --zone=kibana-admin   --add-source=10.20.0.0/16
sudo firewall-cmd --permanent --zone=kibana-admin --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --zone=kibana-admin --list-all

Datastreams en ILM voorbereiden vóórdat u gegevens naar de Elastic Stack verzendt

Maak beleid en sjablonen aan voordat u voor het eerst logs verstuurt. Wijzigingen in sjablonen worden niet met terugwerkende kracht toegepast op bestaande backing-indexen. Voor bestaande streams moet u het huidige ILM-beleid opvragen en vervolgens beleidswijzigingen of rollovers uitvoeren via een aparte procedure. Voer de onderstaande ILM-uitleg pas uit nadat de verzameling is gestart en er een backing-index is aangemaakt.

Als u tijdgebaseerde logs continu naar één index schrijft, worden shards te groot en duurt het herstel langer. Door datastreams en ILM te combineren, kunt u op basis van voorwaarden een rollover naar een nieuwe backing-index uitvoeren en gegevens die de bewaartermijn hebben overschreden automatisch verwijderen. Het onderstaande voorbeeld schakelt over op basis van 50 GB of 1 dag.

ILM-beleid van 30 dagen aanmaken

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_ilm/policy/logs-30d   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {"max_primary_shard_size": "50gb", "max_age": "1d"}
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {"delete": {}}
      }
    }
  }
}
JSON

Indexsjabloon voor datastreams

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_index_template/logs-app   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "index_patterns": ["logs-app-*"],
  "priority": 500,
  "data_stream": {},
  "template": {
    "settings": {
      "index.lifecycle.name": "logs-30d",
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}
JSON

In een single-node oefenomgeving is de clusterstatus ‘yellow’ als replicas=1, omdat er geen node is om de replica-shard aan toe te wijzen. Gebruik replicas=0 alleen voor verificatiedoeleinden of configureer in een productieomgeving minimaal twee datanodes. De bewaartermijn en rollover-drempels moeten worden berekend op basis van het werkelijke dagelijkse volume en het hersteldoel.

Status van ILM-toepassing controleren

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_ilm/status?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/.ds-logs-app-*/_ilm/explain?pretty'

Elastic Stack opbouwen: Logstash- en Filebeat-verwerkingspijplijn

Het lokale voorbeeld toont een stroom waarbij Filebeat gegevens naar Logstash op de loopback stuurt en Logstash het Elasticsearch-certificaat verifieert via de CA. Als externe Beats verbinding maken via 5044, moeten server- en clientcertificaten afzonderlijk worden gedistribueerd en moet de bron van de firewall worden beperkt.

Account met minimale rechten voor gegevensverzameling aanmaken

read -rsp 'elastic password: ' ELASTIC_PASSWORD
echo
read -rsp 'logstash_writer password: ' LOGSTASH_WRITER_PASSWORD
echo

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_security/role/logstash_writer_role   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["logs-app-*"],
      "privileges": ["auto_configure", "create_doc"]
    }
  ]
}
JSON

jq -n --arg password "$LOGSTASH_WRITER_PASSWORD"   '{password:$password,roles:["logstash_writer_role"]}' | curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_security/user/logstash_writer   -H 'Content-Type: application/json' --data-binary @-

unset LOGSTASH_WRITER_PASSWORD

Logstash-configuratiesyntaxis en verbindingsverificatie

sudo install -d -o logstash -g logstash -m 0750 /etc/logstash/certs
sudo install -o logstash -g logstash -m 0640   /etc/elasticsearch/certs/http_ca.crt   /etc/logstash/certs/http_ca.crt

sudo /usr/share/logstash/bin/logstash-keystore   --path.settings /etc/logstash create
sudo /usr/share/logstash/bin/logstash-keystore   --path.settings /etc/logstash add ES_PASSWORD

Het is het principe om voor ES_PASSWORD niet het educatieve ‘elastic’-account te gebruiken, maar een apart aangemaakt account met minimale rechten. De onderstaande configuratie verwijst naar keystore-variabelen in plaats van waarden, zodat er geen geheime informatie in het configuratiebestand achterblijft.

sudo tee /etc/logstash/conf.d/beats-to-elasticsearch.conf >/dev/null <<'EOF'
input {
  beats { host => "127.0.0.1" port => 5044 }
}

filter {
  if ![@metadata][pipeline] { mutate { add_tag => ["pipeline-default"] } }
}

output {
  elasticsearch {
    hosts => ["https://127.0.0.1:9200"]
    user => "logstash_writer"
    password => "${ES_PASSWORD}"
    ssl_enabled => true
    ssl_certificate_authorities => ["/etc/logstash/certs/http_ca.crt"]
    ecs_compatibility => "v8"
    manage_template => false
    ilm_enabled => false
    data_stream => "true"
    data_stream_type => "logs"
    data_stream_dataset => "app"
    data_stream_namespace => "default"
  }
}
EOF

sudo chown logstash:logstash /etc/logstash/logstash.keystore
sudo chmod 0600 /etc/logstash/logstash.keystore

sudo -u logstash /usr/share/logstash/bin/logstash   --path.settings /etc/logstash --config.test_and_exit
sudo systemctl enable --now logstash

Filebeat filestream invoer- en uitvoerinstellingen

sudo tee /etc/filebeat/filebeat.yml >/dev/null <<'EOF'
filebeat.inputs:
  - type: filestream
    id: system-messages
    enabled: true
    paths:
      - /var/log/messages

output.elasticsearch:
  enabled: false

output.logstash:
  hosts: ["127.0.0.1:5044"]

logging.level: info
EOF

sudo filebeat test config -e
sudo filebeat test output -e
sudo systemctl enable --now filebeat
sudo journalctl -u filebeat --since '-10 min' --no-pager

Controleer of Filebeat de rechten heeft om /var/log/messages te lezen. In plaats van het proces onvoorwaardelijk als root uit te voeren, moet u het serviceaccount en het rechtenmodel van het pakket evalueren. Verwijder of redigeer gevoelige velden, persoonlijke gegevens en tokens vóór verzameling. Gebeurtenissen die niet geparseerd kunnen worden, moeten worden geobserveerd via aparte tags en dashboards.

Elastic Stack opbouwen: overschakelen naar een productiecluster met 3 nodes

Bij het opbouwen van een productie-Elastic Stack plaatst u drie master-eligible nodes in verschillende storingsdomeinen. Met slechts twee nodes kan bij een uitval van één node geen meerderheidsconsensus worden behouden. Voeg nieuwe nodes toe via een enrollment token en ruim de discovery-instellingen op nadat alle nodes zijn gevormd.

Node-enrollment en clusterverificatie

U kunt geen nodes toevoegen terwijl de eerdere loopback/single-node instellingen behouden blijven. Verwijder discovery.type: single-node van de bestaande node en wijzig transport.host naar een adres op het privénetwerk dat andere nodes kunnen bereiken. Voor enrollment is ook de HTTPS API van de bestaande node vereist, dus zorg dat http.host ook dat privénetwerkadres en de loopback bevat en controleer de SAN van het certificaat. Sta poort 9200 alleen toe voor de beheerhost die de toevoeging uitvoert, en poort 9300 alleen voor clusternodes. Behoud de TLS-instellingen.

cluster.name: logs-lab
node.name: es01
network.host: 10.20.30.11
http.host: ["127.0.0.1", "10.20.30.11"]
transport.host: 10.20.30.11
discovery.seed_hosts: ["10.20.30.11:9300", "10.20.30.12:9300", "10.20.30.13:9300"]

Vervang de bovenstaande adressen door de werkelijke adressen van de drie nodes en wijzig de bestaande YAML-sleutels. Zorg dat cluster.initial_master_nodes van het bestaande cluster verwijderd blijft. Genereer na een succesvolle bootstrap-check en herstart van de service afzonderlijke tokens voor elke nieuwe node. Controleer ook bij nieuwe nodes vóór de eerste start of de cluster.name, de eigen node.name, het adres en de seed hosts correct zijn.

sudo systemctl restart elasticsearch
sudo systemctl status elasticsearch --no-pager
sudo ss -lntp | grep -E ":(9200|9300)\b"

# Uitvoeren op een bestaand clusterknooppunt
sudo /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token   -s node

# Onmiddellijk na pakketinstallatie uitvoeren op een nieuw knooppunt
sudo /usr/share/elasticsearch/bin/elasticsearch-reconfigure-node   --enrollment-token '<ONE_TIME_NODE_TOKEN>'
sudo systemctl enable --now elasticsearch

# Controleer knooppunten en rollen in het bestaande cluster
curl --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cat/nodes?v&h=name,ip,node.role,master,heap.percent,disk.avail'

cluster.initial_master_nodes wordt alleen gebruikt voor de eerste verkiezing van een nieuw cluster. Verwijder deze instelling van elke node nadat het cluster is gevormd en stel deze niet opnieuw in. Als u deze laat staan bij een herstart, bestaat het risico dat u per ongeluk een apart cluster bootstrapt. Houd in discovery.seed_hosts de master-eligible nodes aan die ook na een herstart bereikbaar zijn.

Elastic Stack opbouwen: snapshots en hersteltraining

Een replica is een kopie om node-uitval op te vangen, geen back-up. Documenten die per ongeluk worden verwijderd, worden onmiddellijk ook uit de replica verwijderd. De voltooiingsvoorwaarden voor het opbouwen van een Elastic Stack moeten een snapshot-repository buiten het cluster, een automatisch SLM-beleid en een daadwerkelijke hersteltest omvatten.

Voorbeeld van registratie van een gedeelde bestandssysteemopslag

Koppel op alle master/data-nodes hetzelfde fysieke gedeelde bestandssysteem op hetzelfde pad en verifieer de lees- en schrijfrechten van het Elasticsearch-serviceaccount. Het aanmaken van afzonderlijke lokale mappen met dezelfde naam op elke node vormt geen gedeelde opslag.

# Bestaande path.repo-sleutel in elasticsearch.yml van alle master-/dataknooppunten
# instellen op path.repo: ["/mnt/elastic-backup"].

# Registreer de opslagplaats na een rollende herstart.
curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT https://127.0.0.1:9200/_snapshot/prod_backup   -H 'Content-Type: application/json' -d @- <<'JSON'
{
  "type": "fs",
  "settings": {
    "location": "/mnt/elastic-backup",
    "compress": true
  }
}
JSON

Validatie van opslagplaatsen en test-snapshots

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X POST 'https://127.0.0.1:9200/_snapshot/prod_backup/_verify?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   -X PUT 'https://127.0.0.1:9200/_snapshot/prod_backup/smoke-test?wait_for_completion=true&pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_snapshot/prod_backup/smoke-test?pretty'

Het kopiëren van /var/lib/elasticsearch op een node via rsync of een filesystem-snapshot wordt niet ondersteund als back-upmethode. De inhoud van de repository kan ook beschadigd raken als deze door een extern proces van Elasticsearch wordt gewijzigd. Voer regelmatig hersteltests uit naar een afzonderlijk testcluster om indexen, feature states en dashboards te controleren.

Validatie van de Elastic Stack-implementatie en probleemoplossing

Controleer de status van services, TLS en het cluster in één keer

systemctl --no-pager --full status   elasticsearch kibana logstash filebeat

sudo ss -lntp | grep -E ':(9200|9300|5601|5044)\b'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cluster/health?pretty'

curl --fail --silent --show-error   --cacert /etc/elastic-client/http_ca.crt   -u "elastic:${ELASTIC_PASSWORD}"   'https://127.0.0.1:9200/_cat/shards?v&s=state,index'

unset ELASTIC_PASSWORD

Diagnostische volgorde

1. Zoek de exit-code van systemd en het tijdstip van de eerste fout in het recente journal.
2. Controleer of poorten alleen op de beoogde adressen luisteren.
3. Controleer de CA, hostnaam, geldigheidsduur en het vertrouwen van de client in het certificaat.
4. Controleer de clustergezondheid op redenen voor niet-toegewezen shards en disk watermarks.
5. Controleer de Logstash-configuratietest, persistente wachtrijen, geweigerde events en de Filebeat-outputtest.
6. Controleer de automatisering van retentie en back-ups met ILM explain en resultaten van snapshot-verificatie.
7. Reproduceer het probleem in een geïsoleerde omgeving met dezelfde invoer en configuratie, en leg de wijzigingen vast.

Veelvoorkomende fouten en alternatieven

Elastic Stack-implementatie: checklist voor upgrades en beheer

• Zorg dat de doelversies van alle componenten gelijk zijn en controleer de release notes en breaking changes.
• Controleer vóór de upgrade de clustergezondheid, niet-toegewezen shards, disk watermarks en het succes van snapshots.
• Voer een rolling upgrade uit per node en wacht bij elke stap tot de node weer deel uitmaakt van het cluster en de shards zijn hersteld.
• Verifieer de compatibiliteit van Kibana saved objects, Logstash-plugins, Beats-modules en aangepaste templates.
• Controleer regelmatig op verlopen certificaten, keystore-items, rotatie van API-keys en het principe van minimale rechten.
• Stel waarschuwingen in voor vertragingen bij gegevensverzameling, JVM-druk, afgewezen verzoeken, shard-grootte en mislukkingen in ILM of SLM.

Gerelateerde bronnen

• Officiële Elastic RPM-installatiedocumentatie
• Officiële Elastic self-managed beveiligingsdocumentatie
• Officiële Elastic ILM-documentatie
• Officiële Elastic Snapshot and Restore-documentatie
• Gids voor het diagnosticeren van schijf- en inode-tekorten in Linux
• Gids voor Ansible-playbooks en rolling deployments
• Gids voor Linux-containers en rootless Podman

Samenvatting van de Elastic Stack-implementatie

De kern van een Elastic Stack-implementatie is niet het succesvolle installatiescherm, maar een operationeel systeem dat veilig gegevens verzamelt, bewaart in voorspelbare groottes en herstel na een storing mogelijk maakt. Begin met officiële pakketten van dezelfde versie en behoud automatische TLS en authenticatie. Valideer vervolgens stapsgewijs de minimale rechten, loopback- en firewallgrenzen, datastreams en ILM, en snapshots buiten het cluster, zodat u een single-node testomgeving kunt uitbreiden naar een operationele structuur met 3 nodes.