다음과 같은 이유로 온프레미스 리소스의 로깅 및 모니터링에 Logging 및 Monitoring을 사용할 수 있습니다.
인프라를Google Cloud 로 전환하는 동안 임시 솔루션을 사용하고자 하며 온프레미스 리소스를 사용 중단 시까지 로깅 및 모니터링하려고 합니다.
여러 클라우드와 온프레미스 리소스가 있는 다양한 컴퓨팅 환경이 있을 수 있습니다.
두 경우 모두 Logging, Monitoring API, BindPlane을 사용하면 온프레미스 리소스를 파악할 수 있습니다. 이 문서는 Google Cloud 의 리소스와 나머지 온프레미스 인프라 및 앱에 대한 로깅 전략에 관심이 있는 DevOps 실무자, 관리자, 경영진을 대상으로 합니다.
Logging으로 로그 수집
다음 두 가지 방법으로 API를 사용하여 로그를 Logging으로 가져올 수 있습니다.
observIQ의 BindPlane을 사용하여 온프레미스나 기타 클라우드 소스에서 로그를 수집합니다.
앱에서 직접 또는 커스텀 에이전트를 통해 Cloud Logging API를 사용합니다.
BindPlane을 사용하여 Logging 로그 수집
다음 다이어그램은 BindPlane을 사용하여 로그를 수집하는 방법과 이러한 로그를 Logging에 수집하는 방법에 대한 아키텍처를 보여줍니다.
BindPlane을 사용하면 사용자가 로그를 수집하려는 호스트에서 원격으로 에이전트를 배포 및 관리할 수 있습니다. 자세한 내용은 BindPlane 아키텍처를 참조하세요.
이 옵션을 사용하면 개발의 필요 없이 구성만 있으면 설정이 가능하므로 배포에 들이는 노력을 최소화할 수 있습니다.
로그 소스가 기본적으로 제공되지 않는 경우 커스텀 구성을 제공해야 할 수 있습니다. 제공된 로그 목록은 소스에서 확인할 수 있습니다.
Logging API 직접 사용
다음 다이어그램은 조정을 통해 로그를 수집하는 방법과 이러한 로그를 Logging으로 수집하는 방법에 대한 아키텍처를 보여줍니다.
API를 직접 사용하려면 애플리케이션을 조정하여 로그를 API에 직접 전송하거나 커스텀 에이전트를 개발하여 로그를 API에 전송해야 합니다. 이는 개발 작업이 요구되므로 많은 노력이 필요한 옵션입니다.
장점:
클라이언트 로깅 라이브러리로 조정을 구현할 수 있으므로 유연성을 제공합니다.
단점:
커스텀 에이전트와 같은 인프라 로그를 위한 별도의 솔루션이 필요합니다.
구현하는 데 많은 비용이 소요될 수 있는 코드 조정이 필요합니다.
적절한 수집 성능을 얻으려면 일괄 처리 및 기타 확장 가능한 수집 기술을 사용해야 합니다.
Logging API에만 지원이 제공되며 커스텀 개발 코드는 지원되지 않습니다.
BindPlane 사용
이 문서에서는 observIQ의 BindPlane을 사용하여 로그를 Logging으로 수집하는 방법을 설명합니다. 이는 Logging 비용에 포함되므로 BindPlane을 사용하면 개발이 필요하지 않으며 제품 지원 솔루션이 제공됩니다.
에이전트, 소스, 대상
에이전트, 소스, 대상에 대한 자세한 내용은 BindPlane 빠른 시작 가이드를 참조하세요.
사용 사례
기업 고객은 BindPlane을 사용하여 다음 온프레미스 로깅 시나리오에서 로그를 수집합니다.
커스텀 애플리케이션 로그에서 로그 데이터의 커스텀 파싱 및 필터링
Linux 또는 Windows 가상 머신의 운영체제 이벤트 수집
네트워크나 다른 호환 기기의 syslog 스트림 수집
Kubernetes 시스템 및 애플리케이션 로그 수집
온프레미스의 로그를 Logging에 전송
BindPlane이 설정되고 로그를 전송하기 시작하면 해당 로그가 Logging에 전송됩니다. 로그 보기, 처리하기, 내보내기 작업을 수행하려면 Google Cloud 콘솔로 이동하세요.
로그는 generic_node 또는 generic_task 리소스 유형으로 나열됩니다. 각 리소스 유형에 포함된 라벨의 자세한 내용은 Logging 리소스 목록을 참조하세요.
Cloud Logging은 다음 두 가지 리소스 유형을 사용하여 Cloud Logging 로그 외의 로그를 지원합니다.
일반 노드: 다른 리소스 유형을 적용할 수 없는 머신 또는 기타 컴퓨팅 리소스를 식별합니다. 라벨 값은 노드를 고유하게 식별해야 합니다.
일반 태스크: 커스텀 조정 시스템에서 예약한 프로세스와 같이 다른 리소스를 적용할 수 없는 앱 프로세스를 식별합니다. 라벨 값은 작업을 고유하게 식별해야 합니다.
로그 항목은 구조화된 로깅 형식을 사용합니다. 이는 로그 페이로드가 jsonPayload로 저장되므로 보다 풍부한 로그 검색 형식을 제공합니다. 페이로드의 필드를 검색의 일부로 사용할 수 있으므로 구조화된 로깅 형식을 사용하면 로그에 더 쉽게 액세스할 수 있습니다. BindPlane 에이전트는 Logging의 원래 로그 항목에서 구조화된 로그 항목까지의 매핑을 제공합니다.
결론
Logging에서 제공되는 로그를 사용하면 Logging 기능을 최대한 활용할 수 있습니다. 로그는 Google Cloud 콘솔에 표시됩니다. Logging 내보내기를 통해 로그를 내보낸 후 로그 기반 측정항목을 사용하여 Monitoring에서 측정항목 및 알림을 만드는 데 사용할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-08-02(UTC)"],[[["\u003cp\u003eThis document explains how to use BindPlane to ingest logs from on-premises infrastructure and applications into Cloud Logging.\u003c/p\u003e\n"],["\u003cp\u003eBindPlane, a third-party tool, allows for remote deployment and management of agents to collect logs without requiring custom development, and is included in the cost of Cloud Logging.\u003c/p\u003e\n"],["\u003cp\u003eAlternatively, logs can be sent directly to the Cloud Logging API, although this method requires code instrumentation or the development of a custom agent, demanding a higher level of effort.\u003c/p\u003e\n"],["\u003cp\u003eOnce logs are in Cloud Logging, they can be viewed, processed, exported, and used to create metrics and alerts in Monitoring, leveraging the \u003ccode\u003egeneric_node\u003c/code\u003e or \u003ccode\u003egeneric_task\u003c/code\u003e resource types for non-cloud resources.\u003c/p\u003e\n"],["\u003cp\u003eThe document outlines various use cases for using BindPlane to ingest log data from custom applications, operating systems, network devices, and Kubernetes environments into Cloud Logging.\u003c/p\u003e\n"]]],[],null,["# Log on-premises resources with BindPlane\n\nThis document is one part of a two-part series on extending\n[Cloud Logging](/logging)\nand\n[Cloud Monitoring](/monitoring)\nto include on-premises infrastructure and apps.\n\n- Log on-premises resources with BindPlane (this document): Read about how Logging supports logging from on-premises resources.\n- [Monitor on-premises resources with BindPlane](/architecture/monitoring-on-premises-resources-with-bindplane): Read about how Monitoring supports monitoring of on-premises resources.\n\nYou might consider using Logging and Monitoring\nfor logging and monitoring of your on-premises resources for the following\nreasons:\n\n- You want a temporary solution while you move infrastructure to Google Cloud and you want to log and monitor your on-premises resources until they're decommissioned.\n- You might have a diverse computing environment with multiple clouds and on-premises resources.\n\nIn either case, with the Logging and Monitoring\nAPIs and\n[BindPlane](https://observiq.com/solutions),\nyou can gain visibility into your on-premises resources. This document is\nintended for DevOps practitioners, managers, and executives who are interested\nin a logging strategy for resources in Google Cloud and their remaining\non-premises infrastructure and apps.\n\nIngesting logs with Logging\n---------------------------\n\nYou can get logs into Logging by using the API in two supported\nways:\n\n- Use BindPlane from observIQ to ingest logs from your on-premises or other cloud sources.\n- Use the Cloud Logging API directly from your app or by using a custom agent.\n\n### Using BindPlane to ingest Logging logs\n\nThe following diagram shows the architecture of how BindPlane ingests logs and\nthen how those logs are ingested into Logging.\n\nBindPlane enables users to remotely deploy and manage agents on the\nhosts they want to gather logs from. For more information, read about\n[the architecture of BindPlane](https://observiq.com/docs/going-to-production/bindplane/architecture/architecture).\nThis option requires the least amount of effort to deploy because it requires\nconfiguration to set up rather than development.\n\nAdvantages:\n\n- Requires configuration, not development.\n- Included in the cost of using [Logging](/stackdriver/pricing).\n- Is a supported configuration by Logging product and support.\n- Can extend to logs not provided by the default configuration.\n\nDisadvantages:\n\n- Requires the use of a third-party tool.\n- Might need to provide a custom configuration if the log source isn't provided by default. The provided list of logs is available in [Sources](https://observiq.com/docs/resources/sources).\n\n### Using the Logging API directly\n\nThe following diagram shows the architecture of how logs are collected by\ninstrumentation and ingested into Logging.\n\nUsing the APIs directly means that you need to instrument your applications to\nsend logs directly to the API or develop a custom agent to send logs to the API.\nThis is the option that requires the highest level of effort because it requires\ndevelopment effort.\n\nAdvantages:\n\n- Provides flexibility because you can implement the instrumentation with client logging libraries.\n\nDisadvantages:\n\n- Requires separate solution for infrastructure logs, such as a custom agent.\n- Requires code instrumentation, which might mean higher cost to implement.\n- Requires the use of batching and other scalable ingestion techniques for proper ingestion performance.\n- Support is provided for the Logging API only, not custom-developed code.\n\nUsing BindPlane\n---------------\n\nThis document covers using BindPlane from observIQ to ingest logs\ninto Logging. Because it's included in the cost of\nLogging, BindPlane doesn't require development and provides a\nproduct-supported solution.\n\n### Agents, sources, and destinations\n\nFor detailed information about agents, sources, and destinations, see\nthe BindPlane [Quickstart\nGuide](https://docs.bindplane.observiq.com/docs/getting-started).\n\n### Example use case\n\nEnterprise customers use BindPlane to ingest logs in the following\non-premises logging scenarios:\n\n1. Custom parsing and filtering of log data from custom application logs.\n2. Collection of operating-system events from Linux or Windows virtual machines.\n3. Ingestion of syslog streams from network or other compatible devices.\n4. Collection of Kubernetes system and application logs.\n\n### Send logs from on-premises to Logging\n\nAfter you set up BindPlane and start sending logs, those logs are sent to\nLogging. To view, process, and export logs, go to the\n[Google Cloud console](https://console.cloud.google.com/logs/query).\nThe logs are listed as `generic_node` or `generic_task`resource types. For\nmore information about the labels included in each resource type, see the\n[Logging resource list](/logging/docs/api/v2/resource-list).\n\nCloud Logging supports non-Cloud Logging logs through the\nuse of two resource types:\n\n- **Generic Node**: Identifies a machine or other computational resource for which no other resource type is applicable. The label values must uniquely identify the node.\n- **Generic Task**: Identifies an app process for which no other resource is applicable, such as a process scheduled by a custom orchestration system. The label values must uniquely identify the task.\n\n### View logs in Logging\n\nOn the [Logs Explorer page](https://console.cloud.google.com/logs/query), the **All resources**\nlist includes **Generic Node** as a resource type.\n\nThe list of logs that appear on the page were captured as the `generic_node` resource type.\nExpand a row to see log entry details.\n\nThe log entries use a\n[structured logging](/logging/docs/structured-logging)\nformat, which provides a richer format for searching the logs because the log\npayload is stored as a `jsonPayload`. The structured logging format makes logs\nmore accessible because you can use the fields in the payload as a part of\nthe search. The BindPlane agent provides a mapping from the original log\nentry to the structured log entry in Logging.\n\nConclusion\n----------\n\nWith logs available in Logging, you can take advantage of the\nfull use of the Logging features. Logs appear in the\nGoogle Cloud console. You can export logs with Logging exports\nand use them to create metrics and alerts in Monitoring by using\n[logs-based metrics](/logging/docs/logs-based-metrics).\n\nWhat's next\n-----------\n\n- [Logging and Monitoring](/stackdriver)\n- [BindPlane set-up instructions for Cloud Monitoring and Logging](https://observiq.com/docs/resources/destinations/google-cloud)\n- [Set up logs-based metrics in Logging](/logging/docs/logs-based-metrics)\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]
