'Log'에 해당하는 글 8건

Logback 구성 파일을 사용하면 코드를 다시 컴파일 할 필요없이 logging 동작을 재정의 할 수도 있다.

구성 파일에 로그를 어떤 형태로 어디에 남길 것인지에 대한 계획도 명시할 수 있으며, 프로그래밍 방식이나 XML, Groovy 형식으로도 작성할 수 있다.

Logback 웹사이트에서 기존 log4j 사용자를 위한 PropertiesTranslator 도 제공한다. (log4j.properties -> logback.xml)



Logback 의 구성 파일 검색 순서


  1. classpath 에서 logback-test.xml 파일 검색.
  2. 없으면 logback.groovy 파일 검색.
  3. 없으면 logback.xml 파일 검색.
  4. 없으면 BasicConfigurator 를 사용하여 logback 을 가장 기본적으로 구성하고, console 로 logging 출력.


src/main/resources 디렉토리에 logback.xml, src/test/resources 디렉토리에 logback-test.xml 파일을 두어 운영/개발에 대한 구성을 분리하여 사용할 수 있다.

구성 파일이 없어서 BasicConfigurator 를 사용하게 되면, root logger 는 DEBUG 레벨이 할당되고 아래의 형식을 가진다.


%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n


// console :

16:06:09.031 [main] INFO  chapters.configuration.MyApp1 - Entering application.

16:06:09.046 [main] DEBUG chapters.configuration.Foo - Did it again!

16:06:09.046 [main] INFO  chapters.configuration.MyApp1 - Exiting application.



logback.xml 구성


아래 코드는 BasicConfigurator 로 기본 설정된 것을 logback-test.xml 이나 logback.xml 파일로 자체 구성한 것이다.


<configuration>
 
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
 
    <root level="debug">
        <appender-ref ref="STDOUT" />
    </root>
</configuration>
cs


이것이 구성 파일을 찾지 못했을 때 적용되는 기본 구성이다.

위 기본 파일 처럼, 구성 파일의 기본적인 구조는 <configuration> 안에 <appender>, <logger>, <root> 순으로 나열하는 것이다.


<appender> 는 name, class 속성을 필수로 지정해야 하며, 선택적으로 하나 이상의 <layout>, <encoder>, <filter> 를 포함할 수 있다.

logback 0.9.19 부터 FileAppender와 하위 클래스는 <encoder> 를 필요로 하고 더 이상 <layout> 을 사용하지 않는다.

<encoder> 는 class 속성을 지정하지 않으면 PatternLayoutEncoder 클래스가 적용된다.

<logger> 는 root 로거와 레벨이나 appender 가 다를 경우 패키지명과 함께 설정한다.

<root> 는 appender 를 참조하여 root 로거에 첨부한다.


아래는 로그를 console 과 file 로 전달하는, 보편적(?)인 logback.xml 스트립트이다.


<?xml version="1.0" encoding="UTF-8"?>
 
<!-- 구성 파일을 수정하였을 때, logback-classic 이 변경 사항을 자동으로 반영하게 한다. -->
<!-- scanPeriod 값의 단위는 milliseconds (default), seconds, minutes, hours 단위로 입력할 수 있다. -->
<!-- StatusPrinter 클래스의 print() 메소드를 호출한 것과 동일하게 logback 의 내부 상태 출력 -->
<configuration scan="true" scanPeriod="30 seconds" debug="true">
 
    <!-- property 요소로 변수를 사용할 수 있다. (아래의 logDir 이나 HOSTNAME 등) -->
    <property resource="resource.properties"/>
 
    <!-- ConsoleAppender 는 거의 이 형식을 벗어나지 않는다. pattern 만 적절히 수정한다. -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern> %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
 
    <!-- RollingFileAppender 는 FileAppender 를 확장한 것으로 파일을 특정 조건에 맞게 로테이션 시키는데 유용하다. -->
    <!-- 아래의 로테이션 정책은 30일이 넘거나 총 파일 크기가 3GB 를 넘기면 오래된 순으로 삭제된다. -->
    <appender name="FILEOUT" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${logDir}/logFile.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>logFile.%d{yyyy-MM-dd}.log</fileNamePattern>
            <maxHistory>30</maxHistory>
            <totalSizeCap>3GB</totalSizeCap>
        </rollingPolicy>
 
        <encoder>
            <pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
        </encoder>
    </appender>
 
    <!-- 아래 logger 들로 특정 라이브러리들에 대한 logger 레벨과 appender 를 지정할 수 있다. -->
    <!-- 여기 지정된 logger 레벨은 root 레벨보다 우선한다. -->
 
    <!-- Hibernate Loggers -->
    <logger name="org.hibernate" level="ERROR">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="FILEOUT"/>
    </logger>
 
    <!-- springframework -->
    <logger name="org.springframework" level="ERROR">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="FILEOUT"/>
    </logger>
 
    <!-- ibatis and mybatis spring -->
    <logger name="org.apache.ibatis" level="INFO">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="FILEOUT"/>
    </logger>
    <logger name="org.mybatis.spring" level="INFO">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="FILEOUT"/>
    </logger>
 
    <!-- if, then, else 구문을 사용하여 서버 환경에 따른 스크립트를 하나의 파일에 동시에 설정할 수 있다. -->
    <!-- 아래는 root 레벨만 조정하였지만, appender-ref 를 변경할 수도 있다. -->
    <if condition='property("HOSTNAME").contains("prod")'>
        <then>
            <root level="info">
                <appender-ref ref="STDOUT"/>
                <appender-ref ref="FILEOUT"/>
            </root>
        </then>
        <else>
            <root level="debug">
                <appender-ref ref="STDOUT"/>
                <appender-ref ref="FILEOUT"/>
            </root>
        </else>
    </if>
</configuration>
cs


구성 파일을 구문 분석하는 동안 경고 또는 오류가 발생하면 Logback 은 내부 상태 데이터를 자동으로 콘솔에 출력한다.

구성 파일의 configuration 요소에 debug="true" 를 설정하면, 오류가 없는 경우에도 구성 파일에 상태 데이터를 출력할 수 있다.

이것은 코드에 StatusPrinter.print() 메소드를 사용한 것과 같은 결과로 나타난다.

또한 설정 파일의 statusListener 요소에 OnConsoleStatusListener 클래스를 설정하는 것과도 같다.





WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Logback 은 Logger, Appender, Layout 의 세 가지 기본 클래스를 기반으로 한다.

이를 사용하여 개발자는 메시지 유형 및 수준에 따라 메시지를 기록하고 런타임에 이러한 메시지의 형식과 보고 위치를 설정할 수 있다.

Logger 클래스는 logback-classic 모듈에 속하고, Appender 및 Layout 인터페이스는 logback-core 에 속하기 때문에, logback-core 에는 logger 의 개념이 없다.



Logger Class


Logger 의 레벨인 TRACE, DEBUG, INFO, WARN, ERROR 는 ch.qos.logback.classic.Level 클래스에 정의된다.

Logger 레벨을 지정하지 않으면 상위 클래스에서 상속받게 되고, default 레벨은 DEBUG 이다.

레벨은 아래와 같으며, 지정된 레벨 이하의 메소드 호출은 기록되지 않는다.


TRACE < DEBUG < INFO < WARN < ERROR



Appenders Class


Appender 는 로그 출력 대상(목적지) 을 설정할 수 있다.

현재 Appender 대상은 console, files, Syslog, TCP Sockets, JMS, DB, JMS 및 원격 UNIX Syslog 데몬이 될 수 있다.



Layouts Class


Appender 와 관련하여 출력 형식을 사용자 정의 하는 것이 Layout 이다.

PatternLayout 을 사용하면 C 언어 printf 함수와 비슷한 변환 패턴에 따라 출력 형식을 지정할 수 있다.

예를 들어 "%-4relative [%thread] %-5level %logger{32} - %msg%n" 같은 패턴을 가진 PatternLayout 의 결과는 다음과 같다.


176  [main] DEBUG manual.architecture.HelloWorld2 - Hello world.
cs



Logging 파라미터


logger.debug("The new entry is "+entry+".");
logger.debug("The new entry is {}.", entry);
cs


위 debug 메소드의 결과는 같지만, 두 번째 debug 메소드가 첫 번째 debug 메소드 형식보다 성능면에서 30배 이상 좋다. 

파라미터 수 만큼 해당 자리에 {} 를 나열하고 이어서 콤마로 구분하여 파라미터를 나열하면 된다.


logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);
cs


배열도 사용 가능하다.


Object[] paramArray = {newVal, below, above};
logger.debug("Value {} was inserted between {} and {}.", paramArray);
cs



내부 동작


사용자가 info() 메소드를 호출할 때 Logback 처리 과정은 다음과 같다.


  1. 필터 체인
    로깅 요청시 TurboFilter 가 존재할 경우 호출되어, 특정 이벤트를 필터링 하여 다음의 응답과 함께 단계 이동한다.
    FilterReply.DENY 이면 Logging 요청 삭제, NEUTRAL 인 경우 2 단계 진행, ACCEPT 인 경우 3 단계 진행.

  2. 기본 선택 규칙 적용
    요청 레벨과 logger 레벨을 비교하여, 사용할 수 없으면 요청을 삭제하고 그렇지 않으면 다음 단계로 진행.

  3. LoggingEvent 객체 생성
    logger, level, message 같은 요청의 모든 파라미터를 포함하는 ch.qos.logback.classic.LoggingEvent 객체를 생성.

  4. Appenders 호출
    LoggingEvent 객체를 만든 후 AppenderBase 의 doAppend() 메소드를 호출하여, 사용자 정의 필터가 있는 경우 해당 필터를 호출.

  5. 출력 형식화 (Layout)
    appender 를 통해, LoggingEvent 인스턴스를 형식화하고 결과를 문자열로 반환.

  6. LoggingEvent 목적지로 보내기
    로깅 이벤트가 완전히 형식화된 후, 각 appender 에 의해 목적지로 전송.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

log4j 를 만든 Ceki Gülcü 는 log4j 를 포함한 다른 logging 시스템들 보다 더 가볍고 빠르게 동작하는 Logback 을 개발하였다.

log4j 와 logback 은 개념적으로 매우 유사하고, log4j 를 사용했던 사용자라면 logback 역시 쉽게 다가갈 수 있다.

System.out.println 와 비교하자면 빠르고, 레벨, 환경 등에 따라 출력 여부를 표시할 수 있다는 점?



Logback 모듈


Logback 은 logback-core, logback-classic, logback-access 세 가지 모듈로 나뉜다.


  • logback-classic 은 log4j 의 향상된 버전에 해당하며, SLF4J API를 기본적으로 구현하여 log4j 이나 JUL 과 같은 다른 로깅 시스템과 쉽게 전환이 가능하다.
  • logback-access 는 Servlet 컨테이너와 통합되어 HTTP 액세스 로그 기능을 제공한다.
  • logback-core 은 위 두 모듈의 기반이 되며, logback 은 이 모듈의 일부인 Joran 이라는 구성 라이브러리에 의존한다. 



Logback 특징


  • logback-classic 모듈의 Logger 클래스가 SLF4J API 를 기본적으로 구현하므로 SLF4J 로거를 호출 할 때 오버 헤드가 발생하지 않는다. 
  • logback-classic 은 설정 파일이 수정되면 자동으로 reload 할 수 있다. 
  • FileAppender 를 비롯한 하위 클래스는 I/O 오류를 정상적으로 복구할 수 있다.
  • 아카이브 된 로그 파일을 자동으로 비동기 압축하며, maxHistory 프로퍼티를 설정하여 오래된 아카이브 로그 파일을 자동으로 삭제할 수 있다.
  • Prudent 모드로 여러 FileAppender 인스턴스로부터 동일한 로그 파일에 안전하게 기록할 수 있다.
  • development, testing, production 같은 다른 환경에 대하여 구성 파일을 중복 구성할 필요없이, 단일 구성 파일에서 조건부 처리를 사용할 수 있다.
    (조건부 처리시 Janino 라이브러리 필요)
  • MDCFilter 를 사용하여 특정 사용자에 대한 Logging Level 지정이 가능하다.
  • SiftingAppender 는 사용자 세션에 따라 로그 파일을 분리할 수 있다.
  • logback 이 exception 을 출력할 때, stack trace 에서 exception 에 개입하는 클래스, 패키지, 패키지 버전을 알 수 있다.
  • logback-Access 모듈은 Jetty, Tomcat 같은 Servlet 컨테이너와 통합되어 풍부하고 강력한 HTTP 액세스 로그 기능을 제공한다.



Logback 요구사항


logback-classic 모듈을 사용하려면, classpath 에 logback-classic.jar 외에도 slf4j-api.jar 와 logback-core.jar 파일이 있어야 한다.

maven 이나 gradle 같은 빌드 툴을 사용할 때는, logback-classic 모듈만 가져오면 slf4j-api.jar, logback-core.jar 파일도 딸려온다.


gradle 예)


dependencies {
    // logback-classic (slf4j-api, logback-core 포함)
    compile group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.3'
}
cs



Logback 구현


package chapters.introduction;
 
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
 
public class HelloWorld1 {
 
    public static void main(String[] args) {
 
        Logger logger = LoggerFactory.getLogger("chapters.introduction.HelloWorld1");
        logger.debug("Hello world.");  // 20:49:07.962 [main] DEBUG chapters.introduction.HelloWorld1 - Hello world.
 
    }
}
cs


"Hello world." 라는 debug 레벨의 로그를 출력하는 예제이다.

SLF4J API 에 정의된 Logger 와 LoggerFactory 를 import 하고, Logger 인스턴스를 생성해서 사용했다.

이 예제처럼, Logging 이 필요한 대부분의 경우 logback 클래스를 참조하지 않고 SLF4J API 만으로 구현해야 한다.


만약 logback 수명주기 동안의 로그가 필요하다면 StatusManager 라는 컴포넌트를 이용할 수 있으며, Logback 관련 문제 진단에 매우 유용할 수 있다.

StatusPrinter 클래스의 print() 메소드를 호출하여 logback 의 내부 상태를 출력할 수 있다.


import ch.qos.logback.classic.LoggerContext;
import ch.qos.logback.core.util.StatusPrinter;
 
...
 
// print internal state
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
StatusPrinter.print(lc);
 
/*
12:49:22.203 [main] DEBUG chapters.introduction.HelloWorld2 - Hello world.
12:49:22,076 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
12:49:22,078 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.xml]
12:49:22,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Setting up default configuration.
*/
cs


위 로그에서 logback 이 구성 파일을 찾지 못하여 기본 정책(ConsoleAppender) 으로 구성되었음을 알 수 있다.

Appender 는 로그를 남길 목적지로, console, files, Syslog, TCP Sockets, JMS 등 다양하게 설정할 수 있다.

에러가 발생하면 logback은 자동으로 내부 상태를 콘솔에 출력한다.



Logback 사용 정리


  1. logback.xml 이나 logback.groovy 같은 구성 설정.
  2. Logging 이 필요한 모든 클래스에 org.slf4j.Logger 인스턴스 생성.
  3. debug(), info(), warn() 및 error() 등 적절한 출력 메소드 호출로 구성된 appender 에 Logging.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

S3 Output Plugin

Tool/Fluentd 2017. 4. 13. 23:10

이제 flentd 의 워크플로우와 설정 파일을 수정하는 방법을 보았으니, 내가 하고자 하는 인프라를 구축하고 td-agent.conf 파일을 수정하면 된다.

input -> (filter) -> match 모델로 거의 모든 다양한 데이터 수집이 가능한데, 흔히 쓰이는 것들을 요약하자면...

웹서버 로그 / 시스템 로그 / Rest API 등을 입력받아, Mongo / Elasticsearch / S3 / Treasure Data 등으로 전달하는 일을 주로 한다.

인터넷을 뒤져보면 더 많은 예제도 찾을 수 있다.


내가 해야 하는 작업은 아래와 같다.


1. 웹 어플리케이션에서 fluent-logger 를 통해

2. fluentd 서버로 메시지 전달

3. 수집된 로그를 가공하여 S3 로 전달

4. AWS Athena 에서 S3 데이터 쿼리


이번 포스트에서는 fluentd 에 관련된 2번, 3번을 설정 파일을 수정하여 해결해 보겠다.



S3 플러그인 설치


td-agent-gem 툴을 이용해 S3 플러그인을 설치한다.


# td-agent-gem install fluent-plugin-s3
Fetching: fluent-plugin-s3-0.8.2.gem (100%)
Successfully installed fluent-plugin-s3-0.8.2
Parsing documentation for fluent-plugin-s3-0.8.2
Installing ri documentation for fluent-plugin-s3-0.8.2
Done installing documentation for fluent-plugin-s3 after 0 seconds
cs


혹시나 아래와 같은 오류가 발생한다면...


Fetching: strptime-0.1.9.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing fluent-plugin-s3:
        ERROR: Failed to build gem native extension.
 
    /opt/td-agent/embedded/bin/ruby -r ./siteconf20170405-3324-1dj4g72.rb extconf.rb
checking for rb_timespec_now()... *** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.
cs


Development Tools 을 설치한다.


# yum groupinstall "Development Tools" "Legacy Software Development"
or
# apt-get install build-essential
cs



td-agent.conf 수정


설정 파일에는 fluent-logger 라이브러리를 통해 forward 타입으로 입력받을 것이고, fluentd 서버가 내부망에 있으므로 외부 접근은 걱정 없다.

forward 로부터 입력받은 이벤트 tag 별로, 별도의 디렉토리에 json 으로 메시지를 쌓고, 1시간에 1번씩 AWS S3 에 로그를 업로드 할 것이다.


# vi /etc/td-agent/td-agent.conf
 
<source>
    @type forward
</source>
 
<match fanbook.*>
    @type s3
 
    aws_key_id YOUR_AWS_KEY_ID
    aws_sec_key YOUR_AWS_SECRET_KEY
    s3_bucket YOUR_S3_BUCKET_NAME
    s3_region YOUR_S3_REGION
 
    path logs/${tag[1]}/%Y/%m/%d/
    s3_object_key_format %{path}%{time_slice}_%{index}.%{file_extension}
    store_as json
 
    <buffer tag,time>
        @type file
        path /var/log/td-agent/s3
        timekey 1h
        timekey_wait 10m
        timekey_use_utc true # use utc
    </buffer>
    <format>
        @type json
    </format>
</match>
cs



위 설정 파일을 간단하게 분석해 보자.

<match> 지시자에 out_s3 플러그인을 설정하였고, 그 아래에는 S3 키/버킷/리전 정보를 입력하였다.

path 파라미터에는 해당 버킷에 레코드가 저장될 경로를 입력한다.

태그/년/월/일을 뜻하는 ${tag}/%Y/%m/%d/ 문법은 v0.14 에서만 표시할 수 있다. v0.12 는 path / s3_object_key_format 에 이 문법을 지원하지 않는다.

오로지 이것 때문에 아직 안정화 되지 않은 v0.14 를 선택했다 ㅡ.ㅡ;

s3_object_key_format 은 업로드할 객체 키로 전체 경로를 입력한다.

store_as 는 어떤 파일로 S3 에 업로드 할 것인지를 결정한다. default 는 압축된 gzip 이지만, json 으로 설정했다. 이 값으로 %{file_extension} 가 결정된다.


output 을 담당하는 <match> 지시자 안에는, 이벤트를 버퍼링하도록 <buffer> 섹션을 넣을 수 있다.

버퍼링은 파일로 저장되도록 @type file 을 설정했다. @type 을 지정하지 않으면 defulat 인 memory 가 설정된다.

태그별로 파일을 만들고 시간 당 업로드를 실행할 계획이므로 <buffer tag,time> 라고 지정하였다.

path 는 버퍼링 파일이 저장될 경로이다.

timekey 는 파일을 생성하여 지정한 시간 동안 버퍼링을 받고 시간이 만료되면 새로운 파일로 버퍼링 처리를 반복한다.

timekey_wait 는 버퍼링 된 파일을 ouput 플러그인(s3) 에서 처리할 시기를 결정한다. 일반적으로 Fluentd 가 지연된 이벤트를 받을 수 있도록 대기시키는 시간이다.

timekey 가 1h 이고 timekey_wait 가 10m 라면, 1시간 10분에 업로드를 시작한다.


<format> 섹션은은 이벤트 형식이다. 기본적인 파일 타입은 out_file 로 예제에서 계속 보아왔던 time|tag|record(json) 이지만, time|tag 를 빼고 record 만 넣기 위해 json 으로 변경하였다.



테스트


input : 

echo '{"json":"message01"}' | /opt/td-agent/embedded/bin/fluent-cat test.hongs
echo '{"json":"message02"}' | /opt/td-agent/embedded/bin/fluent-cat test.hongs
cs


output :

S3/logs/hongs/2017/04/11/201704110320_0.json
 
{"json":"message01"}
{"json":"message02"}
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Plugin parameter

Tool/Fluentd 2017. 4. 12. 23:29

각 Fluentd 플러그인에는 일련의 파라미터가 있다.

예를 들어, in_tail 플러그인에는 rotate_wait 및 pos_file 과 같은 파라미터가 있다. 

각 파라미터에는 연관된 특정 타입이 있으며, 각 다음과 같이 정의된다 :



파라미터 데이터 타입


string

필드가 문자열로 분석된다. 이것은 가장 일반적인 타입으로 각 플러그인이 문자열 처리 방법을 결정한다.

문자열에는 인용되지 않은 한 줄의 문자열, 따옴표(')로 인용된 문자열, 쌍따옴표(")로 인용된 문자열 등으로 구분할 수 있다.


integer

필드가 정수로 분석된다.


float

필드가 부동소숫점으로 분석된다.


size

필드가 바이트 수로 분석되며 몇 가지 표기법이 있다.

- 값이 <INTEGER>k 또는 <INTEGER>K 와 일치하면, 값은 INTEGER(KByte) 이다.

- 값이 <INTEGER>m 또는 <INTEGER>M 과 일치하면, 값은 INTEGER(MByte) 이다.

- 값이 <INTEGER>g 또는 <INTEGER>G 와 일치하면, 값은 INTEGER(GByte) 이다.

- 값이 <INTEGER>t 또는 <INTEGER>T 와 일치하면, 값은 INTEGER(TByte) 이다.

- 나머지는 byte 수이다.


time

필드가 시간으로 분석된다.

- 값이 <INTEGER>s 와 일치하면, 값은 INTEGER(초) 이다.

- 값이 <INTEGER>m 과 일치하면, 값은 INTEGER(분) 이다.

- 값이 <INTEGER>h 와 일치하면, 값은 INTEGER(시) 이다.

- 값이 <INTEGER>d 와 일치하면, 값은 INTEGER(일) 이다.

- 나머지는 float 로 분석되며 float 는 초단위의 수이다. 이 옵션은 "0.1"(=0.1초 = 100ms) 와 같이 1초 미만의 시간을 지정하는 데 유용하다.


array

필드가 JSON 배열로 분석된다.


hash

필드가 JSON 객체로 분석된다.


거의 모든 프로그래밍 언어 및 인프라 도구에서 JSON 값을 쉽게 생성할 수 있기 때문에 array 및 hash 타입은 JSON 형식이다.



플러그인의 공통 파라미터


아래 파라미터들은 시스템 예약어이며, @ 접두사를 가진다.


- @type : 플러그인 타입 지정.

- @id : 플러그인 id 지정. in_monitor_agent 는 plugin_id 필드에 이 값을 사용한다.

- @label : label 기호 지정.

- @log_level : 플러그인 별 로그 수준 지정.


type, id, log_level 은 이전 버전과 호환된다.



Multiple line 


쌍따옴표(") 부호가 있는 string, array, hash 값에 대해 다중 행을 쓸 수 있다.


str_param "foo  # This line is converted to "foo\nbar". NL is kept in the parameter bar"
array_param [
  "a""b"
]
hash_param {
  "k":"v",
  "k1":10
}
cs


Fluentd 는 [ 또는 { 가 array / hash 의 시작으로 판단한다.

따라서 [ 또는 { 시작되었지만 non-json 파라미터를 설정하려면 ' 또는 " 을 사용하라.


예제1: mail 플러그인


<match **>
  @type mail
  subject "[CRITICAL] foo's alert system"
</match>
cs


예제2: map 플러그인


<match tag>
  @type map
  map '[["code." + tag, time, { "code" => record["code"].to_i}], ["time." + tag, time, { "time" => record["time"].to_i}]]'
  multi true
</match>
cs



Ruby 코드 포함


" 인용 부호 string 에서 #{} 부호로 Ruby 코드를 삽입할 수 있다.

이것은 호스트 이름 같은 컴퓨터 정보를 설정하는 데 유용하다.


host_param "#{Socket.gethostname}" # host_param is actual hostname like `webserver1`.
env_param "foo-#{ENV["FOO_BAR"]}" # NOTE that foo-"#{ENV["FOO_BAR"]}" doesn't work.
cs


config-xxx 혼합 형식은 "#{}" 이 아닌 "${}" 을 사용한다.


큰 따옴표로 묶인 string 에서 \는 이스케이프 문자이다.

\는 이스케이프 문자로 해석된다.

큰 따옴표로 묶인 string 에서 \, \r, \n, \t, \ 등에는 \ 를 붙여야 한다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret