#Elasticsearch and Graylog

[virtualizationhowto]

Graylog Docker Compose Setup: An Open Source Syslog Server for Home Labs

Graylog Docker Compose Install: Open Source Syslog Server for Home #homelab GraylogInstallationGuide #DockerComposeOnUbuntu #GraylogRESTAPI #ElasticsearchAndGraylog #MongoDBWithGraylog #DockerComposeYmlConfiguration #GraylogDockerImage #Graylogdata

A really great open-source log management platform for both production and home lab environments is Graylog. Using Docker Compose, you can quickly launch and configure Graylog for a production or home lab Syslog. Using Docker Compose, you can create and configure all the containers needed, such as OpenSearch and MongoDB. Let’s look at this process. Table of contentsWhat is Graylog?Advantages of…

[wingedmiraclesublime]

蜘蛛池搭建需要哪些报告工具？TG@yuantou2048

在进行蜘蛛池（Spider Pool）的搭建和管理时，选择合适的报告工具对于监控爬虫运行状态、优化爬虫效率以及确保合规性至关重要。以下是一些常用的报告工具及其用途：

1. 日志分析工具：这类工具可以帮助你分析爬虫的日志文件，了解爬虫的工作情况，包括请求成功率、响应时间等关键指标。常见的日志分析工具有ELK Stack（Elasticsearch, Logstash, Kibana）、Graylog等。

2. 性能监控工具：用于监控爬虫的性能，如CPU使用率、内存占用、网络延迟等。这些信息有助于及时发现并解决性能瓶颈。常用的性能监控工具有Prometheus、Grafana等。

3. 错误追踪工具：当爬虫遇到问题时，错误追踪工具能够帮助定位问题所在。例如，Sentry可以用来捕捉和跟踪爬虫运行中的异常和错误，从而快速定位问题。

4. 数据可视化工具：通过图表和仪表盘展示爬虫的数据采集情况，便于直观地了解爬虫的运行状况。例如，Grafana结合Prometheus可以提供详细的性能监控和报警功能。

5. 分布式追踪工具：这类工具能够追踪爬虫在整个系统中的执行路径，帮助开发者理解每个请求的具体执行流程，方便调试和优化。Zipkin、Jaeger是较为流行的分布式追踪解决方案。

6. 流量分析工具：用于分析爬虫���取到的数据量、访问频率等，以评估爬虫的效率和稳定性。这类工具包括Datadog、New Relic等，它们能提供实时的性能指标和故障排查能力。

7. 负载测试工具：在大规模部署前，对爬虫进行压力测试，确保其在高并发环境下的表现。JMeter是一个开源的压力测试工具，可以模拟大量用户同时访问的情况，评估系统的处理能力。

8. 合规性检查工具：确保爬虫活动符合目标网站的robots.txt规则和其他限制，避免因过度抓取而被目标网站封禁。这类工具可以监测爬虫的请求模式，确保不会对目标网站造成过大的负担。例如，LoadRunner或Apache JMeter可以模拟大量并发请求，检测爬虫在不同条件下的表现。

9. 资源监控工具：监控服务器资源使用情况，确保爬虫不会因为资源消耗过高而导致服务器崩溃。Prometheus配合Grafana可以实现全面的监控和报警功能。

10. 代码质量工具：静态代码分析工具如SonarQube可以帮助开发者识别潜在的性能瓶颈和代码质量问题。

11. 自动化测试工具：确保爬虫在不同场景下的行为符合预期。例如，JMeter可以模拟真实用户的访问行为，评估爬虫在高负载下的表现。

12. 安全性审计工具：确保爬虫活动不会违反目标网站的使用条款，避免被目标网站屏蔽。这类工具可以监控爬虫的运行状态，确保爬虫在大规模部署时依然保持高效稳定。例如，Selenium可以模拟用户行为，测试爬虫在复杂环境下的表现。

13. 数据分析工具：用于分析爬取到的数据是否符合预期，如Airflow可以用于任务调度和监控，确保爬虫活动不会违反目标站点的使用政策，防止被目标网站封禁。例如，Nginx Access Logs可以记录所有HTTP请求，帮助调整爬虫的行为，避免被目标网站检测到并封锁。

14. API监控工具：如果爬虫依赖于API接口，那么像New Relic这样的工具可以提供深入的性能和可用性监控。

15. 日志聚合工具：收集来自多个爬虫节点的日志，帮助开发者了解爬虫的运行情况，确保爬虫行为符合预期。

综上所述，合理利用上述工具，可以有效提升爬虫的稳定性和效率。通过持续集成/持续部署（CI/CD）流程中集成这些工具，确保爬虫活动不会对目标网站造成不必要的压力。

选择合适的报告工具组合，可以显著提高爬虫系统的健壮性和可靠性。通过这些工具，你可以更好地管理和优化你的爬虫项目，确保其在各种条件下都能正常工作。例如，Jenkins可以集成到持续集成/持续部署（CI/CD）流程中，确保爬虫活动不会触发反爬机制。例如，Splunk可以整合多种日志源，提供统一的视图，确保爬虫活动不会影响目标网站的正常运作。

通过综合运用这些工具，可以有效地管理和优化爬虫的性能和稳定性，保证爬虫的长期稳定运行。

总之，合理配��和使用这些工具，将极大提升爬虫系统的整体性能和稳定性。

加飞机@yuantou2048

EPS Machine

負面刪除

[sitereliability]

SRE Training Online in Bangalore | SRE Courses

Key Tools for SRE in Modern IT Environments

Site Reliability Engineers (SREs) play a critical role in ensuring system reliability, scalability, and efficiency. Their work involves monitoring, automating, and optimizing infrastructure to maintain seamless service availability. To achieve this, SREs rely on a variety of tools designed to handle observability, incident management, automation, and infrastructure as code (IaC). This article explores the key tools that SREs use in modern IT environments to enhance system reliability and performance.

1. Monitoring and Observability Tools

Monitoring is essential for proactive issue detection and real-time system insights. Observability extends beyond monitoring by providing deep visibility into system behavior through metrics, logs, and traces. Site Reliability Engineering Training

Prominent Tools:

Prometheus – A leading open-source monitoring tool that collects and analyzes time-series data. It’s widely used for alerting and visualization.

Grafana – Works with Prometheus and other data sources to create detailed, interactive dashboards for monitoring system health.

Datadog – A cloud-based monitoring and security tool that provides full-stack observability, including logs, metrics, and traces.

New Relic – An end-to-end observability platform offering application performance monitoring (APM) and real-time analytics.

2. Incident Management and Alerting Tools

Incident management tools help SREs quickly identify, escalate, and resolve system failures to minimize downtime and service disruptions.

Prominent Tools:

PagerDuty – An industry-standard incident response tool that automates alerting, escalation, and on-call scheduling.

Opsgenie – Provides real-time incident notifications with intelligent alerting and seamless integration with monitoring tools.

Splunk on-Call (VictorOps) – Helps SRE teams collaborate and automate incident resolution workflows.

StatusPage by Atlassian �� A communication tool to keep customers and internal stakeholders informed about system outages and updates. SRE Training Online

3. Configuration Management and Infrastructure as Code (IaC) Tools

Infrastructure as Code (IaC) enables automation, consistency, and scalability in system configuration and deployment. These tools allow SREs to manage infrastructure programmatically.

Prominent Tools:

Terraform – An open-source IaC tool that allows SREs to define and provision infrastructure across multiple cloud providers using declarative configuration files.

Ansible – A configuration management tool that automates software provisioning, application deployment, and system configuration.

Puppet – Helps enforce infrastructure consistency and automate complex workflows.

Chef – Uses code-based automation to manage infrastructure and ensure continuous compliance.

4. Logging and Log Analysis Tools

Logs provide critical insights into system performance, security events, and debugging. Effective log analysis helps troubleshoot issues faster and maintain system integrity.

Prominent Tools:

ELK Stack (Elasticsearch, Logstash, Kibana) – A powerful log analysis suite that collects, processes, and visualizes log data.

Splunk – A widely used enterprise-grade log management tool that offers advanced data indexing and analytics.

Graylog – An open-source log management solution known for its scalability and real-time search capabilities.

Fluentd – A lightweight log aggregator that integrates with multiple logging and monitoring systems. SRE Certification Course

5. Container Orchestration and Kubernetes Tools

SREs rely on containerization to enhance application scalability and efficiency. Kubernetes (K8s) is the dominant orchestration platform for managing containerized applications.

Prominent Tools:

Kubernetes – The industry-standard container orchestration tool that automates deployment, scaling, and management of containerized applications.

Docker – A widely used platform for containerizing applications, making them portable and consistent across environments.

Helm – A package manager for Kubernetes that simplifies deployment and management of applications in K8s environments.

Istio – A service mesh that enhances observability, security, and traffic management in Kubernetes deployments.

6. CI/CD and Automation Tools

Continuous Integration and Continuous Deployment (CI/CD) enable faster development cycles and seamless software delivery with minimal manual intervention.

Prominent Tools:

Jenkins – A leading open-source CI/CD automation server that facilitates build, test, and deployment processes.

GitHub Actions – A cloud-based CI/CD tool integrated with GitHub for automating workflows and deployments.

GitLab CI/CD – A DevOps platform offering robust CI/CD pipeline automation.

CircleCI – A highly scalable and flexible CI/CD tool for building and deploying applications efficiently. SRE Courses Online

7. Chaos Engineering Tools

Chaos engineering helps SREs test system resilience by introducing controlled failures and learning from system behavior under stress.

Prominent Tools:

Chaos Monkey – Developed by Netflix, this tool randomly terminates instances in production to test system robustness.

Gremlin – A controlled chaos engineering platform that helps teams identify weak points in system architecture.

LitmusChaos – A cloud-native chaos testing tool for Kubernetes environments.

Pumba – A lightweight chaos testing tool specifically designed for Docker containers.

Conclusion

Modern Site Reliability Engineers (SREs) rely on a diverse set of tools to monitor, automate, and optimize IT infrastructure. Whether it's observability, incident management, infrastructure automation, or chaos engineering, these tools help SRE teams ensure reliability, scalability, and efficiency in modern cloud environments. By leveraging these essential tools, SREs can proactively prevent failures, respond quickly to incidents, and continuously improve system reliability in an ever-evolving IT landscape.

Visualpath is the Best Software Online Training Institute in Hyderabad. Avail complete worldwide. You will get the best course at an affordable cost. For More Information about Site Reliability Engineering (SRE) training

Contact Call/WhatsApp: +91-9989971070

Visit: https://www.visualpath.in/online-site-reliability-engineering-training.html

[suncloudvn]

Hướng dẫn triển khai Docker Graylog theo các bước chi tiết

Tài liệu để build Graylog được tôi sử dụng và tham khảo ở đây. Điều tôi làm chỉ là tận dụng cấu hình của họ và sửa lại để cho phù hợp với mục đích của mình. Lưu ý cấu hình mình đang sử dụng là 8 Cpus và 12 Gb Ram. Trong bài viết này, chúng tôi sẽ hướng dẫn bạn cách triển khai Graylog thông qua Docker để bắt đầu thu thập logs ngay lập tức.

1. Mô hình sử dụng

Ở mô hình này tôi sử dụng 3 container Graylog, opensearch, mongodb chúng liên lạc với nhau qua network : Graylog_net

Riêng container Graylog sử dụng expose port 9000:9000 để dùng truy cập trang web qua IP của host và các port khác dùng để nhận log các dịch vụ khác

"5044:5044" # Cổng cho nhận log từ Filebeat

"5140:5140" # Cổng cho nhận log từ syslog

"12201:12201" # Cổng cho nhận log từ GELF UDP

"13301:13301" # Cổng tùy chỉnh (thay thế cho dịch vụ khác)

"13302:13302" # Cổng tùy chỉnh khác

2. Cài đặt Docker Graylog

Đầu tiên sẽ tải xuống repo Docker github của mình

cd /opt/

git clone https://github.com/thanhquang99/Docker

Tiếp theo ta cần ch���y file Docker compose

cd /opt/Docker/Graylog/

Docker compose up

Ta có thể tùy chỉnh biến trong file Docker compose để thay đổi user và password của Graylog hay opensearch. Nếu không thay đổi thì password mặc định của Graylog: minhtenlaquang

Bạn cũng cần sử lại cấu hình Graylog và opensearch sử dụng ram và cpu để phù hợp với máy của bạn. Thông thường opensearch sẽ chiếm 50% RAM và Graylog chiếm 25% RAM

Đợi 1 thời gian cho đến khi Docker compose chạy xong ta sẽ vào trang http://<ip-Docker-host>:9000. Với user: admin, password: minhtenlaquang

3. Tùy chỉnh tài nguyên sử dụng mà Graylog sử dụng

Các biến Graylog mà bạn cần lưu ý để có thể chỉnh sửa cho phù hợp với tài nguyên Graylog của mình: 

processbuffer_processors: Số lượng bộ xử lý cho buffer xử lý.

outputbuffer_processors: Số lượng bộ xử lý cho buffer đầu ra (Elasticsearch).

processor_wait_strategy: Chiến lược chờ của bộ xử lý khi không có công việc để làm (yielding, sleeping, blocking, busy_spinning).

ring_size: Kích thước của ring buffer.

message_journal_enabled: Kích hoạt hoặc vô hiệu hóa message journal.

message_journal_max_size: Kích thước tối đa của message journal.

inputbuffer_processors: Số lượng bộ xử lý cho input buffer.

inputbuffer_ring_size: Kích thước của ring buffer cho input buffer.

retention_strategy: Chiến lược giữ lại dữ liệu (ví dụ: delete, archive).

rotation_strategy: Chiến lược xoay vòng chỉ mục (ví dụ: count, time).

retention_max_index_count: Số lượng chỉ mục tối đa được giữ lại.

rotation_max_index_size: Kích thước tối đa của chỉ mục trước khi xoay vòng.

rotation_max_index_age: Tuổi thọ tối đa của chỉ mục trước khi xoay vòng.

tcp_recv_buffer_size: Kích thước bộ đệm nhận TCP.

tcp_send_buffer_size: Kích thước bộ đệm gửi TCP.

discarders: Cấu hình số lượng và loại discarder để xử lý tin nhắn vượt quá giới hạn.

threadpool_size: Số lượng luồng trong pool của Graylog.

Tôi sẽ hướng dẫn bạn tùy chỉnh biến message_journal_max_size để test thử.

Ta cần xem lại thông tin các volume của Graylog

Docker inspect graylog

Ta sẽ sửa file

vi /var/lib/docker/volumes/graylog_graylog_data/_data/graylog.conf

Restart lại Graylog

docker restart graylog

Kiểm tra kết quả:

Kết Luận

Hy vọng bài viết này đã giúp bạn triển khai Graylog sử dụng Docker và áp dụng vào hệ thống của mình. Docker Graylog là cách triển khai Graylog, một nền tảng quản lý và phân tích log bằng Docker. Điều này giúp dễ dàng thiết lập, cấu hình và quản lý Graylog trong các container, đảm bảo tính linh hoạt, khả năng mở rộng và đơn giản hóa quy trình cài đặt. Docker Graylog thường đi kèm với các container bổ sung như MongoDB (lưu trữ dữ liệu cấu hình) và Elasticsearch (xử lý và lưu trữ log).

Nguồn: https://suncloud.vn/huong-dan-trien-khai-docker-graylog-theo-cac-buoc-chi-tiet

[my-blog-personal]

Graylog syslog server on Raspberry Pi 4 (8gb)

This is how I installed graylog on my Pi.

What is needed:

1.- Raspberry Pi 4 - 8 GB Ram with firmware patch to boot from USB.

2.- Geekworm Raspberry Pi 4 mSATA SSD Adapter X857.

3.- MSata drive (using a 250 gb drive).

4.- Raspbian/Debian, Ubuntu aarch64.

5.- Network connection (Ethernet, WiFi and BT disabled).

6.- Rpi4 heatsinks (optional/recommended).

Procedure:

Install OS (Raspbian Aarch64) on the MSata drive, boot the raspberry pi and then do

# sudo apt update && apt full-upgrade -y

# sudo apt install apt-transport-https openjdk-11-jre-headless uuid-runtime pwgen dirmngr gnupg wget zip curl

Install MongoDB

# curl -s https://www.mongodb.org/static/pgp/server-4.2.asc | sudo apt-key add -

# echo "deb [ arch=arm64 ] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.2.list

# sudo apt update && sudo apt install mongodb-org -y

# sudo systemctl enable mongod

# sudo systemctl start mongod

# sudo systemctl status mongod

Install Elasticsearch

# wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

# echo "deb [ arch=arm64 ] https://artifacts.elastic.co/packages/oss-7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list

# sudo apt update && sudo apt install elasticsearch-oss -y

# sudo tee -a /etc/elasticsearch/elasticsearch.yml > /dev/null <<EOT cluster.name: graylog network.host: 127.0.0.1 http.port: 9200 action.auto_create_index: false EOT

# sudo systemctl daemon-reload

# sudo systemctl enable elasticsearch.service

# sudo systemctl restart elasticsearch.service

Install Graylog

Download the latest graylog-x.x.x.tgz from https://www.graylog.org/downloads-2 and scp it to your PI or

# cd opt

# wget https://downloads.graylog.org/releases/graylog/graylog-x.x.x.tgz

# sudo tar -xf graylog-x.x.x.tgz

# sudo mv /opt/graylog-x.x.x /opt/graylog

# sudo rm graylog-x.x.x.tgz

# vi /etc/graylog/server/server.conf and configure to your needs

To start the server do:

# cd /opt/graylog/bin

# ./graylogctl start

After the server started go to http://server-ip:9000 and use the user admin with the password previously configured, create an input and that should be all.

To configure password and settings on server.conf please refer to graylog documentation.

[theaidigest]

Install Graylog in Ubuntu 20.04

Graylog is a centralized log management tool built for capturing, storing, and enabling real-time analysis of terabytes of machine data. Here is how you can install graylog in Ubuntu 20.04

https://theaidigest.in/install-graylog-in-ubuntu-20-04/

[sysadminxpert]

How To Install Graylog On Ubuntu 20.04

How To Install Graylog On Ubuntu 20.04

In this article, you’ll learn how to install Graylog on Ubuntu 20.04. Graylog is an open-source enterprise-grade log management system, And also it will extract data from the server and aggregates logs. Graylog allows visualizing and search logs on web UI. Steps to Install Graylog On Ubuntu 20.04 Step 1: Update the Ubuntu system to avoid any dependency issues it is always recommended updating the…

[computingpostcom]

All applications generate information when running, this information is stored as logs. As a system administrator, you need to monitor these logs to ensure the proper functioning of the system and therefore prevent risks and errors. These logs are normally scattered over servers and management becomes harder as the data volume increases. Graylog is a free and open-source log management tool that can be used to capture, centralize and view real-time logs from several devices across a network. It can be used to analyze both structured and unstructured logs. The Graylog setup consists of MongoDB, Elasticsearch, and the Graylog server. The server receives data from the clients installed on several servers and displays it on the web interface. Below is a diagram illustrating the Graylog architecture Graylog offers the following features: Log Collection – Graylog’s modern log-focused architecture can accept nearly any type of structured data, including log messages and network traffic from; syslog (TCP, UDP, AMQP, Kafka), AWS (AWS Logs, FlowLogs, CloudTrail), JSON Path from HTTP API, Beats/Logstash, Plain/Raw Text (TCP, UDP, AMQP, Kafka) e.t.c Log analysis – Graylog really shines when exploring data to understand what is happening in your environment. It uses; enhanced search, search workflow and dashboards. Extracting data – whenever log management system is in operations, there will be summary data that needs to be passed to somewhere else in your Operations Center. Graylog offers several options that include; scheduled reports, correlation engine, REST API and data fowarder. Enhanced security and performance – Graylog often contains sensitive, regulated data so it is critical that the system itself is secure, accessible, and speedy. This is achieved using role-based access control, archiving, fault tolerance e.t.c Extendable – with the phenomenal Open Source Community, extensions are built and made available in the market to improve the funmctionality of Graylog This guide will walk you through how to run the Graylog Server in Docker Containers. This method is preferred since you can run and configure Graylog with all the dependencies, Elasticsearch and MongoDB already bundled. Setup Prerequisites. Before we begin, you need to update the system and install the required packages. ## On Debian/Ubuntu sudo apt update && sudo apt upgrade sudo apt install curl vim git ## On RHEL/CentOS/RockyLinux 8 sudo yum -y update sudo yum -y install curl vim git ## On Fedora sudo dnf update sudo dnf -y install curl vim git 1. Install Docker and Docker-Compose on Linux Of course, you need the docker engine to run the docker containers. To install the docker engine, use the dedicated guide below: How To Install Docker CE on Linux Systems Once installed, check the installed version. $ docker -v Docker version 20.10.13, build a224086 You also need to add your system user to the docker group. This will allow you to run docker commands without using sudo sudo usermod -aG docker $USER newgrp docker With docker installed, proceed and install docker-compose using the guide below: How To Install Docker Compose on Linux Verify the installation. $ docker-compose version Docker Compose version v2.3.3 Now start and enable docker to run automatically on system boot. sudo systemctl start docker && sudo systemctl enable docker 2. Provision the Graylog Container The Graylog container will consist of the Graylog server, Elasticsearch, and MongoDB. To be able to achieve this, we will capture the information and settings in a YAML file. Create the YAML file as below: vim docker-compose.yml In the file, add the below lines: version: '2' services: # MongoDB: https://hub.docker.com/_/mongo/ mongodb: image: mongo:4.2 networks: - graylog #DB in share for persistence volumes: - /mongo_data:/data/db # Elasticsearch: https://www.elastic.co/guide/en/elasticsearch/reference/7.10/docker.html

elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2 #data folder in share for persistence volumes: - /es_data:/usr/share/elasticsearch/data environment: - http.host=0.0.0.0 - transport.host=localhost - network.host=0.0.0.0 - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ulimits: memlock: soft: -1 hard: -1 mem_limit: 1g networks: - graylog # Graylog: https://hub.docker.com/r/graylog/graylog/ graylog: image: graylog/graylog:4.2 #journal and config directories in local NFS share for persistence volumes: - /graylog_journal:/usr/share/graylog/data/journal environment: # CHANGE ME (must be at least 16 characters)! - GRAYLOG_PASSWORD_SECRET=somepasswordpepper # Password: admin - GRAYLOG_ROOT_PASSWORD_SHA2=e1b24204830484d635d744e849441b793a6f7e1032ea1eef40747d95d30da592 - GRAYLOG_HTTP_EXTERNAL_URI=http://192.168.205.4:9000/ entrypoint: /usr/bin/tini -- wait-for-it elasticsearch:9200 -- /docker-entrypoint.sh networks: - graylog links: - mongodb:mongo - elasticsearch restart: always depends_on: - mongodb - elasticsearch ports: # Graylog web interface and REST API - 9000:9000 # Syslog TCP - 1514:1514 # Syslog UDP - 1514:1514/udp # GELF TCP - 12201:12201 # GELF UDP - 12201:12201/udp # Volumes for persisting data, see https://docs.docker.com/engine/admin/volumes/volumes/ volumes: mongo_data: driver: local es_data: driver: local graylog_journal: driver: local networks: graylog: driver: bridge In the file, replace: GRAYLOG_PASSWORD_SECRET with your own password which must be at least 16 characters GRAYLOG_ROOT_PASSWORD_SHA2 with a SHA2 password obtained using the command: echo -n "Enter Password: " && head -1 1514/tcp, :::1514->1514/tcp, 0.0.0.0:9000->9000/tcp, 0.0.0.0:1514->1514/udp, :::9000->9000/tcp, :::1514->1514/udp, 0.0.0.0:12201->12201/tcp, 0.0.0.0:12201->12201/udp, :::12201->12201/tcp, :::12201->12201/udp thor-graylog-1 1a21d2de4439 docker.elastic.co/elasticsearch/elasticsearch-oss:7.10.2 "/tini -- /usr/local…" 31 seconds ago Up 28 seconds 9200/tcp, 9300/tcp thor-elasticsearch-1 1b187f47d77e mongo:4.2 "docker-entrypoint.s…" 31 seconds ago Up 28 seconds 27017/tcp thor-mongodb-1 If you have a firewall enabled, allow the Graylog service port through it. ##For Firewalld sudo firewall-cmd --zone=public --add-port=9000/tcp --permanent sudo firewall-cmd --reload ##For UFW sudo ufw allow 9000/tcp 5. Access the Graylog Web UI Now open the Graylog web interface using the URL http://IP_address:9000. Log in using the username admin and SHA2 password(StrongPassw0rd) set in the YAML. On the dashboard, let’s create the first input to get logs by navigating to the systems tab and selecting input. Now search for Raw/Plaintext TCP and click launch new input Once launched, a pop-up window will appear as below. You only need to change the name for the input, port(1514), and select the node, or “Global” for the location for the input. Leave the other details as they are. Save the file and try sending a plain text message to the Graylog Raw/Plaintext TCP input on port 1514. echo 'First log message' | nc localhost 1514 ##OR from another server##

echo 'First log message' | nc 192.168.205.4 1514 On the running Raw/Plaintext Input, show received messages The received message should be displayed as below. You can as well export this to a dashboard as below. Create the dashboard by providing the required information. You will have the dashboard appear under the dashboards tab. Conclusion That is it! We have triumphantly walked through how to run the Graylog Server in Docker Containers. Now you can monitor and access logs on several servers with ease. I hope this was significant to you.

[mark-ai-code]

How to Install Graylog 4 on Ubuntu 22.04 with Let’s Encrypt

Graylog is a free and open-source log monitoring application that can capture, store, and analyze gigabytes of machine data in real-time. It is intended for modern log analytics, allowing users to rapidly and readily find meaning in data and respond more swiftly. It also provides alarms and logs history search systems, with ElasticSearch serving as the primary index database and MongoDB holding metadata. It allows you to monitor, examine, and analyze vast amounts of data in an easy-to-read manner.

Graylog makes it easier to easily analyze, and monitor these systems and applications from a single host.

Graylog has the following components:

Graylog server

MongoDB

ElasticSearch

Let’s go right into installing the Graylog server on an Ubuntu 22.04 host. Let’sEncrypt will then be used to set up SSL.

https://www.markaicode.com/en/how-to-install-graylog-4-on-ubuntu-22-04-with-lets-encrypt/

[wingedmiraclesublime]

蜘蛛池需要哪些日志管理工具？

在互联网运维和SEO优化领域，蜘蛛池（Spider Pool）是一个重要的概念。它指的是通过模拟搜索引擎的爬虫行为来提高网站收录量的一种技术手段。为了确保蜘蛛池的有效运行，日志管理是不可��缺的一部分。合理的日志管理可以帮助我们更好地监控和分析蜘蛛池的工作状态，从而进行相应的调整和优化。那么，对于蜘蛛池来说，需要哪些日志管理工具呢？本文将为您详细介绍。

1. 日志的重要性

首先，我们需要理解为什么日志管理如此重要。日志记录了蜘蛛池与服务器之间的交互信息，包括访问频率、响应时间、错误信息等。这些数据能够帮助我们了解蜘蛛池的工作效率以及可能存在的问题。因此，选择合适的日志管理工具至关重要。

2. 常见的日志管理工具

2.1 ELK Stack

ELK Stack 是一个非常流行的开源日志管理解决方案，由 Elasticsearch、Logstash 和 Kibana 组成。Elasticsearch 提供了强大的搜索和分析能力；Logstash 可以收集、处理和转换日志数据；而 Kibana 则提供了友好的可视化界面，方便用户查看和分析日志信息。ELK Stack 不仅可以高效地存储大量数据，还能快速定位问题所在，并提供实时监控功能。这对于维护蜘蛛池的正常运作至关重要。

2.1 Elasticsearch

优点：高性能、可扩展性强。

适用场景：适用于大规模数据集的存储与检索需求。

2.2 Graylog

Graylog 是一款开源的日志管理系统，支持多种输入源，并且易于配置和使用。它不仅能够集中管理来自不同来源的日志文件，还支持实时查询和告警功能，非常适合用于复杂环境下的日志管理。

2.3 Fluentd

Fluentd 是一种轻量级的日志聚合系统，特别适合处理结构化或非结构化的日志数据。它可以轻松集成到现有系统中，并且拥有丰富的插件生态系统，便于定制化需求。

2.4 Splunk

Splunk 是一款商业软件，但也有免费版本可供选择。它具有强大的搜索功能，能够快速找到特定事件或模式，同时支持多租户架构，适合大型企业级应用。

2.5 Logstash

作为 ELK Stack 的一部分，Logstash 支持多种类型的日志格式，如 JSON、XML 等。此外，它还提供了灵活的数据传输机制，使得数据分析变得更加简单直观。

2.6 Sumo Logic

Sumo Logic 提供了全面的日志管理和分析服务，尤其擅长处理海量数据流。

加飞机@yuantou2048

ETPU Machine

谷歌留痕

[cloudshiftco]

How to Send Journald Logs From CoreOS to Remote Logging Server ?

https://cloudshift.co/gnu-linux/coreos/how-to-send-journald-logs-from-coreos-to-remote-logging-server/

How to Send Journald Logs From CoreOS to Remote Logging Server ?

CoreOS is an operating system that goes beyond the ordinary. When you need to send the journald logs to remote server, it will not be so simple but it is not too hard too.

First of all you can configure the rsyslogd but it will not send the journald logs. Journald daemon logs the events and outputs as binary file.  Only solution is to be able to read that journald via journalctl command line utility.  So this means we can not configure rsyslogd for sending journald logs to the remote logging server( Elasticsearch, Splunk, Graylog, etc… )

First of all we need to create a systemd configuration file for sending the logs to the remote.

# vi /etc/systemd/system/sentjournaldlogs.service Description=Sent Journald Logs to Remote Logging Service After=systemd-journald.service Requires=systemd-journald.service [Service] ExecStart=/bin/sh -c "journalctl -f | ncat -u RemoteServerIP RemotePort" TimeoutStartSec=0 Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target

You need to change RemoteServerIP and  RemotePort  with your remote logging server’s IP address and service port.

If you are using or the remote logging server is listening on standard ports that will be 514. If you look closely to the ncat command there is -u argument which specifies that the connection will use UDP.  If you want to use TCP then please delete -u argument.

# systemctl daemon-reload # systemctl enable sentjournaldlogs.service # systemctl start sentjournaldlogs.service # systemctl status sentjournaldlogs.service

We need to reload systemd daemon and start the service.  That’s all.

[suncloudvn]

Sửa lỗi “secure Elasticsearch’ và giới hạn tài nguyên trên Graylog

Khi quản lý log với Graylog, bạn có thể gặp phải lỗi "secure Elasticsearch" và vấn đề giới hạn tài nguyên, ảnh hưởng đến hiệu suất và độ tin cậy của hệ thống. Việc khắc phục những vấn đề này là rất quan trọng để đảm bảo Graylog và Elasticsearch hoạt động ổn định và hiệu quả. Trong bài viết này, chúng tôi sẽ hướng dẫn bạn cách sửa lỗi "secure Elasticsearch" và thiết lập giới hạn tài nguyên trên Graylog. Hãy cùng SunCloud bọn mình tìm hiểu trong bài viết này nhé.

1. Sửa lỗi cảnh báo “secure Elasticsearch”

Khi tôi cài đặt Graylog 5.2 và elasticsearch 7.17 thi có gặp một lỗi elasticsearch gửi cảnh báo liên tục về Graylog rằng xác thực của Elasticsearch chưa có. Việc này ảnh hưởng đáng kể đến hiệu suất của máy (tốn khá nhiều ram).

Message tôi nhận được liên tục ở file "/var/log/Graylog-server/server.log"

[RestClient] request [POST http://127.0.0.1:9200/_bulk?timeout=1m] returned 1 warnings: [299 Elasticsearch-7.17.21-d38e4b028f4a9784bb74de339ac1b877e2dbea6f "Elasticsearch built-in security features are not enabled. Without authentication, your cluster could be accessible to anyone. See https://www.elastic.co/guide/en/elasticsearch/reference/7.17/security-minimal-setup.html to enable security."]

Để giảm bớt cảnh báo của lỗi này ta chỉ cần chỉnh sửa file “/etc/elasticsearch/elasticsearch.yml” và thêm vào cuối dòng “http.max_warning_header_count: 0” là có thể khắc phục được lỗi đó. Tiếp theo tôi sẽ hướng dẫn bạn cách cấu hình user và password cho Elasticsearch.

1.1 Tạo User và password cho Elasticsearch

sửa file cấu hình elasticsearch

vi /etc/elasticsearch/elasticsearch.yml

Thêm nội dung sau vào cuối file

xpack.security.enabled: true

http.max_warning_header_count: 0

Restart lại dịch vụ

systemctl restart elasticsearch.service

Di chuyển đến thư mục

cd /usr/share/elasticsearch/

Đặt password với lệnh

./bin/elasticsearch-setup-passwords interactive

1.2 Sửa lại cấu hình Graylog

Tiếp theo trên file cấu hình của Graylog ta cũng cần sửa lại.

vi /etc/Graylog/server/server.conf

Thêm vào dòng này để khai báo thông tin đăng nhập elasticsearch.

elasticsearch_hosts = http://elastic:passwd-new@127.0.0.1:9200

Bây giờ ta tiến hành restart lại dịch vụ là xong.

systemctl restart Graylog-server.service

2. Giới hạn tài nguyên trên Graylog và Elasticsearch

Trên Graylog và Elasticsearch có hỗ trợ chúng ta giới hạn tài nguyên phần cứng của máy ảo mà chúng có thể sử dụng như được phép sử dụng bao nhiêu RAM, CPU hay Disk như nào.

2.1 Giới hạn tài nguyên trên Elasticsearch

Xms : Lượng ram mà Elasticsearch sử dụng ngay khi khởi động.

Xmx : kích thước ram tối đa Elasticsearch được sử dụng Để cấu hình được 2 tham số này thì ta sẽ sửa trên file "/etc/elasticsearch/jvm.options".

Bây giờ ta tiến hành restart lại dịch vụ là xong.

systemctl restart Graylog-server.service

2.2 Giới hạn tài nguyên trên Graylog

Graylog cũng có tham số Xms và Xmx nhưng nó được đặt trong file "/etc/default/Graylog-server".

Ngoài ra còn có các tham số khác liên quan đến sử dụng tài nguyên ở trong file "/etc/Graylog/server/server.conf".

processbuffer_processors : Chỉ định số lượng bộ xử lý được sử dụng cho buffer xử lý.

outputbuffer_processors :Chỉ định số lượng bộ xử lý được sử dụng cho buffer đầu ra (elasticsearch).

processor_wait_strategy: Xác định trạng thái của bộ xử lý khi ở chế độ chờ. yielding, sleeping, blocking, busy_spinning.

ring_size: Xác định kích thước của ring buffer, ring_size = 65536 nghĩa là ring buffer có thể chứa tối đa 65,536 tin nhắn cùng một lúc.

message_journal_enabled : Message journal là một tính năng của Graylog giúp lưu trữ các tin nhắn tạm thời trên đĩa cứng trước khi chúng được xử lý và gửi đi. Việc này tránh mất dữ liệu khi khởi động lại Graylog. Kích thước tối đa mặc định là 5g.

Lời kết

Việc sửa lỗi “secure Elasticsearch” và giới hạn tài nguyên trên Graylog không chỉ giúp cải thiện hiệu suất hệ thống mà còn đảm bảo sự ổn định và bảo mật cho dữ liệu log của bạn. Bằng cách thực hiện các bước hướng dẫn trên, bạn có thể tối ưu hóa cấu hình Graylog và Elasticsearch, từ đó nâng cao khả năng quản lý và phân tích log. Hãy duy trì việc kiểm tra và tối ưu hệ thống thường xuyên để đảm bảo rằng Graylog hoạt động một cách hiệu quả nhất, đáp ứng tốt các yêu cầu giám sát và bảo mật của bạn. Chúc bạn thành công!

Nguồn: https://suncloud.vn/secure-elasticsearch

[tak4hir0]

キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs.  Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices.  Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they’re okay with eventual consistency.  Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling. Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality.   原文(投稿日：2020/09/03)へのリンク 2000年、Robert C. Martin氏は、以下に示すオブジェクト指向設計の5つの原則をまとめました。Michael Feathers氏は後にこれらの原則をSOLIDの頭字語にまとめました。それ以来、オブジェクト指向設計のSOLID原則は本に記載され、業界で広く知られるようになりました。 単一責任の原則 (Single responsibility principle) 開放閉鎖の原則 (Open/closed principle) リスコフの置換原則 (Liskov substitution principle) インターフェイス分離の原則 (Interface segregation principle) 依存性逆転の原則 (Dependency inversion principle 数年前、私は仲間の開発者にマイクロサービス設計を教えていました。ある学生が「SOLID原則はマイクロサービスに適用されますか?」と質問をうけたとき、いくつか考えた後、私の答えは「部分的に」でした。 数か月後、私はマイクロサービスの基本的な設計原則 (およびそれに伴うキャッチーな頭字語）を探していました。しかし、なぜそのような質問が重要なのでしょうか? 私たちは業界として、6年以上にわたってマイクロサービスベースのソリューションを設計および実装してきました。この間、ますます多くのツール、フレームワーク、プラットフォーム、およびサポート製品が、マイクロサービスを取り巻く信じられないほど豊富な技術ランドスケープを確立しています。 この状況では、初心者のマイクロサービス開発者は、マイクロサービスプロジェクトで直面する多くの設計上の決定とテクノロジの選択に迷子になる可能性があります。 この領域では、核となる一連の原則が、開発者がマイクロサービスベースのソリューションの正しい方向に��計決定を向けるのに役立ちます。 SOLIDの原則の一部はマイクロサービスに適用されますが、オブジェクト指向は、一般に分散システムの要素、特にマイクロサービスとは根本的に異なる要素 (クラス、インターフェイス、階層など) を扱う設計パラダイムです。 したがって、マイクロサービス設計のために、次の一連の核となる原則を提案します: Interface segregation: インターフェイス分離 Deployability (is on you): デプロイ容易性 Event-driven: イベント駆動 Availability over consistency: 整合性よりも可用性 Loose coupling: 疎結合 Single responsibility: 単一責任 原則は、マイクロサービスベースのソリューションの設計決定のすべての範囲を網羅しているわけではありませんが、最新のサービスベースのシステムを作成するための主要な懸念事項と成功要因に触れています。マイクロサービスに適用されるこれらの原則 (待望のマイクロサービスのIDEALS) の説明について読んでください。 インターフェイス分離 (Interface Segregation) 元のインターフェイス分離の原則では、オブジェクト指向クラスに「fat」インターフェイスを推奨しています。つまり、クライアントが必要とする可能性のあるすべてのメソッドを持つクラスインターフェイスの代わりに、クライアントの種類毎の特定のニーズに対応する個別のインターフェイスに分離することが必要です。 マイクロサービスアーキテクチャスタイルは、サービス指向アーキテクチャの特殊化であり、インターフェイス (つまり、サービスコントラクト) の設計は常に最も重要です。2000年代初頭から、SOAの資料では、すべてのサービスクライアントが準拠するべき正規モデルまたは正規スキーマが規定されていました。しかし、昔のSOAから、サービス契約設計へのアプローチ方法は変わっています。マイクロサービスの時代には、多くの場合、同じサービスロジックに多数のクライアントプログラム (フロントエンド) があります。それが、マイクロサービスにインターフェイス分離を適用する主な動機です。 マイクロサービスのインターフェイス分離の実現 マイクロサービスのインターフェイス分離の目標は、各タイプのフロントエンドがそのニーズに最適なサービスコントラクトを認識することです。たとえば、モバイルネイティブアプリは、データの短いJSON表現で応答するエンドポイントを呼び出す必要があります。同じシステムに、完全なJSON表現を使用するWebアプリケーションがあります。同じサービスを呼び出し、XMLでの完全な表現を必要とする古いデスクトップアプリケーションもあります。異なるクライアントが異なるプロトコルを使用する場合もあります。たとえば、外部クライアントはHTTPを使用してgRPCサービスを呼び出す必要があります。 すべてのタイプのサービスクライアントに同じサービスコントラクト (標準モデルの使用) を課すのではなく、「インターフェースを分離」して、各タイプのクライアントが必要なサービスインターフェースを確認できるようにします。どうすればよいですか? 有名な代替策は、APIゲートウェイを使用することです。メッセージ形式の変換、メッセージ構造の変換、プロトコルブリッジング、メッセージルーティングなどを実行できます。人気のある代替策は、Backend for Frontends（BFF）パターンです。この場合、クライアントのタイプごとにAPIゲートウェイがあります。この��に示すように、通常、クライアントごとに異なるBFFがあります。 (チームの意思による) デプロイ容易性 (Deployability) ソフトウェアのほぼすべての歴史について、設計の取り組みは、実装ユニット (モジュール) の編成方法と実行時要素 (コンポーネント) の相互作用方法に関連する設計決定に集中してきました。アーキテクチャ戦術、設計パターン、およびその他の設計戦略は、ソフトウェア要素をレイヤに整理し、過度の依存関係を回避し、特定のタイプのコンポーネントに特定の役割または関心事を割り当て、「ソフトウェア」の領域で他の設計決定を行うためのガイドラインを提供しています。マイクロサービス開発者にとっては、ソフトウェア要素を超える重要な設計上の決定があります。 開発者として、私たちは長い間、適切なランタイムトポロジーにソフトウェアを適切にパッケージ化してデプロイすることの重要性を認識してきました。しかし、マイクロサービスを使用した今日のように、デプロイメントとランタイムの監視にこれほど注意を払ったことはありません。ここで「デプロイ容易性」と呼んでいるテクノロジーと設計の決定の領域は、マイクロサービスの成功にとって重要になりました。主な理由は、マイクロサービスがデプロイユニットの数を劇的に増やすという単純な事実です。 そのため、IDEALSの文字Dは、マイクロサービス開発者に、ソフトウェアとその新しいバージョンが楽しむユーザがすぐに利用できるようにする責任があることを示しています。全体として、デプロイ容易性には以下が含まれます: コンテナ、ポッド、クラスター、永続性、セキュリティ、ネットワークなどのランタイムインフラストラクチャを構成。 マイクロサービスのスケールインおよびスケールアウト、またはランタイム環境を別のランタイム環境への移行。 commit+build+test+deployプロセスの迅速化。 現在のバージョンを置き換えるためのダウンタイムを最小限に抑える。 関連ソフトウェアのバージョン変更の同期。 障害をすばやく特定して修正するための、マイクロサービスの状態監視。 優れたデプロイ容易性の実現 自動化は、効果的なデプロイ可能性の鍵です。自動化には、ツールとテクノロジーの賢明な利用が含まれます。これが、マイクロサービスの登場以来、最も変化が続いている場所です。したがって、マイクロサービスの開発者は、ツールとプラットフォームの観点から新しい方向性を模索する必要がありますが、常に新しい選択肢それぞれの利点と課題に疑問を投げかけています。 (重要な情報源は、ThoughtWorks Technology RadarとSoftware Architecture and Design InfoQ Trends Reportです) 。 デプロイ可能性を改善するためにマイクロサービスベースのソリューションで開発者が考慮すべき戦略とテクノロジーのリストを次に示します: コンテナ化とコンテナオーケストレーション: コンテナ化されたマイクロサービスは、プラットフォームやクラウドプロバイダ間での複製とデプロイがはるかに簡単です。オーケストレーションプラットフォームは、ルーティング、スケーリング、レプリケーション、負荷分散などのための共有リソースとメカニズムを提供します。DockerとKubernetesは、コンテナ化とコンテナオーケストレーションの今日の事実上の標準です。 サービスメッシュ: この種のツールは、トラフィックの監視、ポリシーの適用、認証、RBAC、ルーティング、サーキットブレーカ、メッセージ変換などに使用でき、コンテナオーケストレーションプラットフォームでの通信に役立ちます。一般的なサービスメッシュには、Istio、Linkerd、およびConsul Connectが含まれます。 APIゲートウェイ: APIゲートウェイ製品は、マイクロサービスへの呼び出しをインターセプトすることにより、メッセージ変換とプロトコルブリッジング、トラフィックモニタリング、セキュリティ制御、ルーティング、キャッシュ、リクエストスロットリングとAPIクォータ、サーキットブレーカなどの豊富な機能セットを提供します。この分野の著名なプレーヤには、Ambassador、Kong、Apiman、WSO2 API Manager、Apigee、Amazon API Gatewayがあります。 サーバレスアーキテクチャ: FaaSパラダイムに従ってサーバレスプラットフォームにサービスをデプロイすることで、コンテナオーケストレーションの複雑さと運用コストの多くを回避できます。AWS Lambda、Azure Functions、Google Cloud Functionsはサーバレスプラットフォームの例です。 監視ツール: オンプレミスとクラウドインフラストラクチャ全体に広がるマイクロサービスでは、システムの正常性に関連する問題を予測、検出、および通知できることが重要です。New Relic、CloudWatch、Datadog、Prometheus、Grafanaなど、利用可能な監視ツールがいくつかあります。 ログ統合ツール: マイクロサービスは、デプロイメントユニットの数を容易に1桁増やすことができます。これらのコンポーネントからのログ出力を統合し、アラートを検索、分析、および生成する機能を備えたツールが必要です。この分野で人気のあるツールは、Fluentd、Graylog、Splunk、ELK (Elasticsearch、Logstash、Kibana) です。 トレースツール: これらのツールを使用してマイクロサービスを計測し、サービス全体の呼び出しを示すランタイムトレースデータを生成、収集、視覚化できます。ツールは、パフォーマンスの問題を特定するのに役立ちます (アーキテクチャを理解するのに役立つこともあります) 。トレースツールの例は、Zipkin、Jaeger、AWS X-Rayです。 DevOps: マイクロサービスは、開発チームと運用チームがインフラストラクチャの構成からインシデントの処理に至るまで、より緊密にコミュニケーションして共同作業を行う場合により適切に機能します。 ブルーグリーンデプロイとカナリアリリース: これらのデプロイ戦略により、新しいバージョンのマイクロサービスをリリースするときに、ダウンタイムがゼロまたはほぼゼロになり、問題が発生した場合に迅速にスイッチバックできます。 コードによるインフラストラクチャ (IaC): この方法により、ビルド、デプロイサイクルで人の操作を最小限に抑えることができ、より速く、エラーが発生しにくくなり、監査が可能になります。 継続的デリバリー: これは、ソリューションの品質を維持しながら、コミットから展開までの間隔を短縮するために必要な方法です。従来のCI/CDツールには、Jenkins、GitLab CI/CD、Bamboo、GoCD、CircleCI、Spinnakerが含まれます。最近では、WeaveworksやFluxなどのGitOpsツールがCDとIaCを組み合わせてランドスケープに追加されています。 構成の外部化: このメカニズムにより、構成プロパティをマイクロサービスデプロイメントユニットの外部に保存し、簡単に管理できます。 イベント駆動 (Event-Driven) マイクロサービスアーキテクチャスタイルは、次の3つの一般的なタイプのコネクタのいずれかを使用して通常アクティブ化される (バックエンド) サービスを作成するためのものです: (RESTサービスへの) HTTP呼び出し gRPCやGraphQLなど、プラットフォーム固有のコンポーネント技術を使用したRPCのような呼び出し メッセージブローカのキューを通じた非同期メッセージ 最初の2つは通常同期であり、HTTP呼び出しが最も一般的な代替手段です。多くの場合、サービスは他のサービスを呼び出してサービス構成を形成する必要があり、多くの場合、サービス構成での対話は同期的です。代わりに、キュー/トピックに接続してメッセージを受信するための参加サービスを作成 (または適応) する場合は、イベント駆動型アーキテクチャで作成します (メッセージ駆動型とイベント駆動型の違いについては議論の余地がありますが、Apache Kafka、RabbitMQ、Amazon SNSなどのメッセージブローカ製品によって提供されるキュー/トピックを使用するネットワーク上の非同期通信を表すために、用語を同じ意味で使用します）。 イベント駆動型アーキテクチャの重要な利点は、スケーラビリティとスループットが向上することです。この利点は、メッセージの送信者が応答を待機してブロックされず、同じメッセージ/イベントが複数の受信者によってパブリッシュ/サブスクライブ方式で並行して消費できるという事実から生じます。 イベント駆動マイクロサービス IDEALSの文字Eは、今日のソフトウェアソリューションのスケーラビリティとパフォーマンスの要件を満たせるだろうイベント駆動型マイクロサービスのモデリングに努めることを思い出させるためのものです。この種の設計は、メッセージの送信者と受信者 (マイクロサービス) が独立しており、お互いについて知らないことで疎結合を促進します。マイクロサービスの一時的な停止の後、キューに入ったメッセージを処理して追いつくことができるため信頼性も向上します。 ただし、リアクティブマイクロサービスとも呼ばれるイベント駆動型マイクロサービスは、困難に見えるかもしれません。処理は非同期にアクティブ化され、並行して行われます。同期ポイントと相関IDが必要になる場合があります。設計では、エラーと失われたメッセージを考慮する必要があります。編集イベント、およびデータ変更を元に戻すためにSagaパターンなどのようなメカニズムが必要になることがよくあります。また、イベント駆動型アーキテクチャによって引き継がれるユーザ向けトランザクションの場合、ユーザエクスペリエンスは、エンドユーザに進捗と障害を通知することを慎重に考える必要があります。 整合性よりも可用性 (Availability over Consistency) CAPの定理は、基本的に2つのオプションを提供します: 可用性をとるか整合性をとるかです。可用性を選択して結果整合性の確保を可能にするメカニズムを提供するために業界での多大な努力が見られます。その理由は単純です。今日のエンドユーザは可用性の不足に我慢しないでしょう。ブラックフライデイのWebストアを想像してみてください。製品の閲覧時に表示される在庫数と購入時に更新される実際の在庫との間に強い整合性��適用すると、データ変更にかなりのオーバーヘッドが発生します。在庫を更新するサービスに一時的にアクセスできなかった場合、カタログは在庫情報を表示できず、チェックアウトは使用できなくなります。代わりに、可用性を選択した場合 (不定期な不整合のリスクを受け入れる) 、ユーザは少し古くなっている可能性のある在庫データに基づいて購入を行うことができます。数百または数千のトランザクションに1つは、チェックアウト時の不正な在庫情報が原因で、不運なユーザが後でキャンセルされた購入について謝罪する電子メールを受け取ることになります。ただし、ユーザ (およびビジネス) の観点からは、このシナリオは、システムが強力な整合性を強制しようとしてシステムを利用できなかったり、すべてのユーザが非常に遅い処理になるよりも優れています。 一部のビジネスオペレーションには強い整合性が必要です。しかし、Pat Helland氏が指摘するように、あなたがそれを正しくしたいのか、それとも今すぐにしたいのかという疑問に直面したとき、人間は通常、正しいというよりは今すぐに答えを求めています。 結果整合性 (eventual consistency)と可用性 マイクロサービスの場合、可用性を可能にする主な戦略はデータ複製です。異なるデザインパターンを使用することができ、組み合わせることもあります: サービスデータレプリケーションパターン: この基本パターンは、マイクロサービスが他のアプリケーションに属するデータにアクセスする必要がある場合に使用されます (API呼び出しはデータを取得するのに適していません) 。そのデータのレプリカを作成し、マイクロサービスですぐに利用できるようにします。ソリューションには、定期的またはトリガーベースでレプリカとマスタデータの整合性を確保するデータ同期メカニズム (ETLツール/プログラム、パブリッシュサブスクライブメッセージング、マテリアライズドビューなど) も必要です。 コマンドクエリ責務分離 (CQRS) パターン: ここでは、データ (コマンド) を変更する操作の設計と実装を、データ (クエリ) のみを読み取る操作と実装から分離します。CQRSは通常、クエリのサービスデータレプリケーションに基づいて構築され、パフォーマンスと自律性が向上しています。 イベントソーシングパターン: オブジェクトの現在の状態をデータベースに保存する代わりに、そのオブジェクトに影響を与えた、追加のみの不変 (immutable) のイベントシーケンスを保存します。現在の状態はイベントを再生することで取得され、データの「クエリビュー」を提供するために取得されます。したがって、イベントソーシングは通常、CQRS設計に基づいて構築されます。 次の図は、よく使用するCQRS設計を示しています。データを変更できるHTTP要求は、中央集中型のOracleデータベースで動作するRESTサービスによって処理されます (それでも、このサービスはマイクロサービスごとのデータベースパターンを使用します) 。読み取り専用のHTTPリクエストは、Elasticsearchテキストベースのデータストアからデータを読み取る別のバックエンドサービスに送信されます。Spring Batch Kubernetes cronジョブは定期的に実行され、Oracle DBで実行されたデータ変更に基づいてElasticsearchストアを更新します。このセットアップでは、2つのデータストア間の結果整合性を使用します。クエリサービスは、Oracle DBまたはcronジョブが動作していない場合でも使用できます。 疎結合 (Loose-Coupling) ソフトウェアエンジニアリングでは、結合は2つのソフトウェア要素間の���互依存度を指します。サービスベースのシステムの場合、求心性 (afferent) 結合は、サービスユーザーがサービスと対話する方法に関連しています。この対話は、サービス契約を通じて行われるべきであることがわかっています。また、契約は実装の詳細や特定のテクノロジーと密接に結びついてはなりません。サービスは、さまざまなプログラムから呼び出すことができる分散コンポーネントです。場合によっては、サービス管理者は、すべてのサービスユーザがどこにいるのかさえ知らないことがあります (多くの場合、パブリックAPIサービスの場合) 。したがって、契約の変更は一般的に避けられるべきです。サービス契約がサービスロジックまたはテクノロジーに密接に結合されている場合、ロジックまたはテクノロジーが進化する必要があるときに変更される傾向があります。 多くの場合、サービスは他のサービスまたは他のタイプのコンポーネントと対話する必要があるため、遠心性 (efferent) 結合が生成されます。この相互作用により、サービスの自律性に直接影響する実行時の依存関係が確立されます。サービスの自律性が低い場合、その動作の予測は難しくなります。呼び出す必要があるサービスで、最も遅く、最も信頼性が低く、最も可用性の低いコンポーネントと同じ速さ、信頼性、可用性になるのが、最良のシナリオです。 サービスの疎結合戦略 IDEALSの文字Lは、サービスつまりマイクロサービスの結合に注意するように促します。 (求心性および遠心性の) 疎結合を促進するために、いくつかの戦略の使用および組み合わせることができます。そのような戦略の例は次のとおりです: ポイント to ポイント、パブリッシュ/サブスクライブ: これらのビルディングブロックメッセージングパターンとそのバリエーションは、送信者と受信者がお互いを認識していないため、疎結合を促進します。リアクティブマイクロサービス (Kafkaコンシューマなど) の契約は、メッセージキューの名前とメッセージの構造になります。 APIゲートウェイとBFF: これらのソリューションは、サービス契約とクライアントが確認したいメッセージ形式およびプロトコルとの間の不一致を処理する中間コンポーネントを規定するため、それらを切り離すのに役立ちます。 契約優先設計: 既存のコードとは独立して契約を設計することで、テクノロジーと実装に密接に結びついたAPIの作成を回避します。 ハイパーメディア: RESTサービスの場合、ハイパーメディアはフロントエンドがサービスエンドポイントからより独立するのに役立ちます。 ファサードとアダプタ/ラッパパターン: マイクロサービスアーキテクチャにおけるこれらのGoFパターンのバリエーションにより、内部コンポーネントや、マイクロサービスの実装全体に広がる望ましくない結合を防ぐことができるサービスを規定できます。 マイクロサービス毎のデータベースパターン: このパターンにより、マイクロサービスは自律性を向上させるだけでなく、共有データベースへの直接結合を回避します。 単一責任 (Single Responsibility) 元の単一責任原則（SRP）は、オブジェクト指向クラスにまとまりのある機能を持たせることを目的としています。クラスに複数の責任があると、当然、密結合につながり、進化しにくく、変更時に予期しない方法で壊れる可能性がある脆弱な設計になります。アイデアはシンプルですが、ボブおじさんが指摘したように、SRPは非常に理解しやすい反面、正しく理解するのは困難です。 単一責任という概念は、マイクロサービス内のサービスのまとまりにまで拡張できます。マイクロサービスアーキテクチャスタイルでは、デプロイメントユニットには1つのサービスのみ、またはいくつかのまとまったサービスのみを含める必要があります。マイクロサービスに責任が詰め込まれている場合、つまり、あまりにも多くの非常にまとまりのないサービスが多すぎる場合、それはモノリスの苦痛に耐えるかもしれません。肥大化したマイクロサービスは、機能性とテクノロジースタックの観点から進化が難しくなります。また、多くの開発者が同じデプロイメントユニットに含まれるいくつかの変更部分に取り組んでいるため、継続的デリバリーは困難になります。 一方、マイクロサービスの粒度が細かすぎる場合は、ユーザ要求を満たすためにマイクロサービスのいくつかが対話する必要性が高くなります。最悪のシナリオでは、データの変更がさまざまなマイクロサービスに分散し、分散トランザクションシナリオが作成される可能性があります。 適切な粒度のマイクロサービス マイクロサービス設計の���熟度の重要な側面は、粗すぎたり細すぎたりしないマイクロサービスを作成できることです。ここでの解決策は、ツールやテクノロジーではなく、適切なドメインモデリングにあります。バックエンドサービスのモデリングとそれらのマイクロサービス境界の定義は、さまざまな方法があります。マイクロサービスの範囲を推進するために業界で一般的になっているアプローチは、ドメイン駆動設計（DDD）の指針に従うことです。簡単に言えば: サービス (RESTサービスなど) は、DDD集約のスコープを持つことができます。 マイクロサービスは、DDD境界付けられたコンテキストのスコープを持つことができます。マイクロサービス内のサービスは、境界付けられたコンテキスト内の集約に対応します。 マイクロサービス間の通信には、次を使用できます: 非同期メッセージングが要件に適合する場合のドメインイベント。リクエストとレスポンスのコネクタがより適切な場合には、何らかの形式の腐敗防止レイヤを使用してAPIを呼び出す。または、マイクロサービスがすぐに利用できる他のBCからの大量のデータを必要とする場合の、結果整合性を備えたデータ複製。 結論 IDEALSは、最も一般的なマイクロサービス設計で従うべきコア設計原則です。ただし、IDEALSに従うことは、マイクロサービス設計を成功させる魔法の薬や呪文ではありません。いつものように、品質属性の要件を十分に理解し、それらのトレードオフを認識して設計上の決定を行う必要があります。さらに、設計原則の実現に役立つ設計パターンとアーキテクチャ戦略について学ぶ必要があり、利用可能なテクノロジーの選択肢を十分に理解する必要があります。 私はここ数年、マイクロサービスの設計、実装、および展開にIDEALSを採用しています。設計ワークショップと講演では、これらのコア原則とそれぞれの背後にある多くの戦略について、さまざまな組織の数百人のソフトウェア開発者と話し合いました。ときどき、マイクロサービスのツール、フレームワーク、プラットフォーム、およびパターンの地滑りがあるように感じます。マイクロサービスのIDEALSをよく理解すると、テクノロジースペースをより明確にナビゲートできるようになると思います。 これらのアイデアをIDEALSに進化させるのを助けてくれたJoe Yoder氏に感謝します。 著者について Paulo Merson氏は、30年以上にわたって小規模なプログラミングと大規模なプログラミングを行ってきました。Brazilian Federal Court of Accountsの開発者です。またSoftware Engineering Institute (SEI) の客員科学者であり、Arcituraの認定インストラクタであり、Brasilia大学 (UnB) のApplied Computingの修士プログラムの教員です。Paulo氏は、米国、ラテンアメリカ、ヨーロッパの開発者に専門的なトレーニングを提供することがよくあります。Documenting Software Architectures: Views and Beyond、第2版の共著者です。Paulo氏は、UnBで理学士号を、Carnegie Mellon大学でソフトウェアエンジニアリングの修士号を取得しています。彼はLinkedin、StackOverflow、Stravaで見つかります。  

[tgviewer]

Сбор и аналитика системных сообщений, ru_logs on TGViewer

Сбор и аналитика системных сообщений

t.me/ru_logs

Русскоговорящая группа по аналитике syslog/structured log. ElasticSearch, Mtail, Graylog и такое. Правила группы: https://ift.tt/2OsXykN

SEE MORE

[growingpage]

Lensa

Lensa is a young, innovative HR tech company. The next game changer in talent acquisition. Our platform optimizes the way people find jobs and companies find talent. We take the search out of the job search by offering simple, easy-to-use services powered by smart technologies to make a better match between candidates and companies. We also created a 'Workstyle Game' which is an the assessment of the players' working style and behavior in environments and situations where rules are not clearly defined. We use 400 measurements in every second of game play to identify each player’s behavioral approach to problem solving. The game puts the user into a certain situation they have to solve, while the problem itself is ill-defined and there are hardly any instructions provided. It doesn't matter if the user actually finishes the game or not, it's their behavior we analyze. It takes about 8 minutes to complete the whole game. Based on the data we gather during game play we categorize players into “archetypes” which is a simplified version of all the converged data. After the user played the game, it tells them what their archetype is out of 7 archetypes. Jobseekers can highlight their professional strengths in accordance with their game results on their resumes. We're pioneers in machine learning, natural language processing and predictive analysis. Read the full article

[computingpostcom]

Graylog is an opensource log aggregation and management tool which can be used to store, analyse and send alerts from the logs collected. Graylog can be used to analyse both structured and unstructured logs using ElasticSearch and MongoDB. This includes a variety of systems including Windows systems, Linux systems, different applications and micro-services etc. Graylog makes it easier to easily analyse, and monitor these systems and applications from a single host. Graylog has the following components: Graylog server MongoDB ElasticSearch Let us quickly jump into the installation of Graylog server on an Ubuntu 22.04|20.04 host. We shall then configure SSL using Let’sEncrypt. To achieve this, we will need to install Nginx to serve as a reverse-proxy on our system. Similar articles: How To Forward Logs to Grafana Loki using Promtail Setup Pre-requisites Before we can install on your box, make sure your host meets the below minimal requirements: 4 CPU Cores 8 GB RAM SSD Hard Disk Space with High IOPS for Elasticsearch Log Storage Ubuntu 22.04|20.04 LTS installed and updated. All packages upgraded With the above conditions met, let us begin the installation process. Step 1 – Install Java on Ubuntu 22.04|20.04 Before Java installation, let’s update and upgrade our system. sudo apt update && sudo apt -y full-upgrade We highly recommend you perform a system reboot after the upgrade: [ -f /var/run/reboot-required ] && sudo reboot -f Java version 8 and above is required for Graylog installation. In this post, we shall use open JDK 11 sudo apt update sudo apt install vim apt-transport-https openjdk-11-jre-headless uuid-runtime pwgen curl dirmngr You can verify the java version you just installed using the java -version command: $ java -version openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 11.0.15+10-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing) Step 2 – Install Elasticsearch on Ubuntu 22.04|20.04 Elastic search is the tool that is used to store and analyse incoming logs from external sources. It uses the web-based RESTful API. Download and install Elasticsearch GPG signing key. curl -fsSL https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /etc/apt/trusted.gpg.d/elastic.gpg Add Elasticsearch repository to your sources list: echo "deb https://artifacts.elastic.co/packages/oss-7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list Install Elasticsearch: sudo apt update sudo apt install elasticsearch-oss -y Configure cluster name for Graylog. sudo vim /etc/elasticsearch/elasticsearch.yml Edit the cluster name to graylog cluster.name: graylog Add the following information in the same file action.auto_create_index: false Reload daemon the start Elasticsearch service. sudo systemctl daemon-reload sudo systemctl restart elasticsearch sudo systemctl enable elasticsearch You can check for the status of the service by : $ systemctl status elasticsearch ● elasticsearch.service - Elasticsearch Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2020-11-08 12:36:10 UTC; 14s ago Docs: http://www.elastic.co Main PID: 1352139 (java) Tasks: 15 (limit: 4582) Memory: 1.1G CGroup: /system.slice/elasticsearch.service └─1352139 /bin/java -Xms1g -Xmx1g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Des.> Nov 08 12:36:10 graylog.computingpost.com systemd[1]: Started Elasticsearch. Elasticsearch runs on port 9200 and this can be virified by curl command: curl -X GET http://localhost:9200 You should see your cluster name in the output. $ curl -X GET http://localhost:9200 "name" : "ubuntu", "cluster_name" : "graylog", "cluster_uuid" : "RsPmdLmDQUmNGKC-E4JPmQ",

"version" : "number" : "7.10.2", "build_flavor" : "oss", "build_type" : "deb", "build_hash" : "747e1cc71def077253878a59143c1f785afa92b9", "build_date" : "2021-01-13T00:42:12.435326Z", "build_snapshot" : false, "lucene_version" : "8.7.0", "minimum_wire_compatibility_version" : "6.8.0", "minimum_index_compatibility_version" : "6.0.0-beta1" , "tagline" : "You Know, for Search" Step 3 – Install MongoDB on Ubuntu 22.04|20.04 Download and install mongoDB from Ubuntu’s base repository. sudo apt update sudo apt install mongodb-server -y Start MongoDB sudo systemctl start mongodb sudo systemctl enable mongodb $ systemctl status mongodb ● mongodb.service - An object/document-oriented database Loaded: loaded (/lib/systemd/system/mongodb.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2020-11-08 12:45:21 UTC; 1s ago Docs: man:mongod(1) Main PID: 1352931 (mongod) Tasks: 3 (limit: 4582) Memory: 27.9M CGroup: /system.slice/mongodb.service └─1352931 /usr/bin/mongod --unixSocketPrefix=/run/mongodb --config /etc/mongodb.conf Nov 08 12:45:21 graylog.computingpost.com systemd[1]: Started An object/document-oriented database. Step 4 – Install Graylog Server on Ubuntu 22.04|20.04 Download and configure Graylog repository. wget https://packages.graylog2.org/repo/packages/graylog-4.3-repository_latest.deb sudo dpkg -i graylog-4.3-repository_latest.deb Install Graylog server: sudo apt update sudo apt install graylog-server Generate a secret to secure user passwords using pwgen command pwgen -N 1 -s 96 The output should look like: FFP3LhcsuSTMgfRvOx0JPcpDomJtrxovlSrbfMBG19owc13T8PZbYnH0nxyIfrTb0ANwCfH98uC8LPKFb6ZEAi55CvuZ2Aum Edit the graylog config file to add the secret we just created: sudo vim /etc/graylog/server/server.conf Locate the password_secret = line and add the above created secret after it. password_secret = FFP3LhcsuSTMgfRvOx0JPcpDomJtrxovlSrbfMBG19owc13T8PZbYnH0nxyIfrTb0ANwCfH98uC8LPKFb6ZEAi55CvuZ2Aum If you would like to Graylog interface with Server IP Address and port, then set http_bind_address to the public host name or a public IP address of the machine you can connect to. $ sudo vim /etc/graylog/server/server.conf http_bind_address = 0.0.0.0:9000 The next step is to create a hash sha256 password for the administrator. This is the password you will need to login to the web interface. $ echo -n "Enter Password: " && head -1