타사 플러그인 설치 기능 사용

Macerel의 플러그인 기능으로 매우 편리합니다.
mackerel-agent-plguins, go-check-plugins 모두 유연하게 활용할 수 있다.
사용한 플러그인은 다음과 같습니다.

mackerel-agent-plugins

mackerel-plugin-apache2

mackerel-plugin-docker

mackerel-plugin-jvm

mackerel-plugin-memcached

mackerel-plugin-mysql

mackerel-plugin-nginx

mackerel-plugin-postgres

go-check-plugins

check-http

check-log

check-procs

check-tcp

또한 Macerel은 플러그인을 직접 만들어 사용할 수 있다는 장점이 있습니다.
나도 스스로 몇 개의 플러그인을 만들어서 사용했다.
며칠 전에 내가 기대했던 것을 발표했다타사 플러그인 설치 기능.
이 기능이 등장하기 전에 구축된 바이너리를 어딘가에 두고 맥켈 설정 때 나눠주거나 맥켈을 설치한 환경에 Go를 설치해 매번 구축해야 한다.
내 사용 환경에서 Macerel 설정에 사용된Ansible의 창고에 구축된 2진법을 넣고 나누어 주기 때문에 창고가 비대화되고 2진법이 언제 구축되었는지 알 수 없는 문제가 존재한다.
이번에는 실제 플러그인을 설치하는 것부터 제3자 플러그인을 설치하는 기능까지 일련의 절차를 시도해 보려고 합니다.

우선 플러그인 설치

중요한 플러그인 소재는 사실상 공개 이전부터 사용해온 비공개 형태로 진행됐다.
며칠 전 송무씨가 살짝 개조소개하다mackerel-plugin-accesslog한 물건입니다.
글에서도 flentd를 사용한 합계 방법을 소개했는데, 이전부터 계속 사용해 왔다mackerel-plugin-accesslog면 더 편리할 텐데, 내 환경에서는 LTCV 포맷이 대응하지 않아 사용하지 못했다.
플러그인의 실현은 글에서 설명한 바와 같이 ltsv.org 기록reqtime과 status의Key가 필요하지만 제 환경에서 다른 형식을 사용했습니다.
메이커엘 이외의 로그의 의존성을 활용할 때 포맷을 바꾸기 어렵다는 점을 고려해 키를 선택하려 했지만, 설치mackerel-plugin-accesslog에서는 어려울 것 같아 풀 리퀘스트 형식이 아닌 나름의 방식으로 리모델링했다.
이것은mackerel-plugin-ltsv-accesslog입니다.

GiitHub Releases로 발행

플러그인 설치가 완료된 경우mkr plugin install 가능한 상태여야 합니다.<release_tag>는 <repo>_<GOOS>_<GOARCH>.zip의 명명 규칙에 따라 구축된 산물만 배치할 수 있다.

플러그인 구성

플러그인 구축에서 교차 컴파일goxc을 사용할 수 있습니다.

### インストール
$ go get github.com/laher/goxc

### クロスコンパイル
$ goxc

샘플로 공개mackerel-plugin-sample된 goxc의 구축 설정이 있기 때문에 이렇게 빌려씁니다.
다음 파일을 창고 밑에 직접 놓으세요.
이렇게 하면 Linux, Mac, Windows의 32비트, 64비트 환경에서 실행되는 바이너리는 플러그인<repo>_<GOOS>_<GOARCH>.zip의 명칭 규칙으로 생성될 것으로 기대된다.
.goxc.json

{
    "ArtifactsDest": "dist",
    "Tasks": [
        "clean-destination",
        "xc",
        "archive-zip",
        "rmbin"
    ],
    "TaskSettings": {
        "archive-zip": {
            "include-top-level-dir": "windows darwin linux",
            "platforms": "windows darwin linux"
        }
    },
    "Arch": "386 amd64",
    "Os": "linux darwin windows",
    "ConfigVersion": "0.9"
}

결과 자동 게시

어렵기 때문에 GiitHub에서 Push 후 자동 테스트 -> 구축 버전으로 설정했습니다.
CI는 CircleaCI 및 GiitHub Releases의 릴리즈ghr를 사용합니다.
기릿허브의 창고와 서클래식(CircleaCI)을 합친 뒤 창고 내에서만 제작.circleci/config.yml해 푸시를 진행한다.
config.yml

version: 2
jobs:
  test:
    working_directory: /go/src/github.com/nashiox/mackerel-plugin-ltsv-accesslog
    docker:
      - image: golang:1.9
    steps:
      - checkout
      - run:
          name: "Install Build Dependencies"
          command: |
              make builddep
      - run:
          name: "Run Test"
          command: make test

  deploy:
    working_directory: /go/src/github.com/nashiox/mackerel-plugin-ltsv-accesslog
    docker:
      - image: golang:1.9
    steps:
      - checkout
      - run:
          name: "Install Build Dependencies"
          command: make builddep
      - run:
          name: "Cross Compile"
          command: make cross
      - run:
          name: "Deploy"
          command: make deploy

workflows:
  version: 2
  test_and_deploy:
    jobs:
      - test
      - deploy:
          requires:
            - test
          filters:
            branches:
              only: master

테스트, 구축, 디버깅에 필요한 명령을 모두 Makefile에 의뢰합니다.
CircleciCI 2.0workflows 기능test을 사용하는 것은 전체 지점이며, deploy은 마스터 지점에 Push를 할 때만 실행된다.
여기 도착하면 GiitHub에서만 Push를 해요.
마스터 지점에서 Push를 진행하면 탭이 다음과 같이 표시되며 플러그인이 발표됩니다.

설정

그리고 실제적으로 감시를 설치했을 뿐입니다.
설치는 다음 규칙<GitHubのリポジトリ>@<タグ>에 따라 지정됩니다.

$ mkr plugin install nashiox/[email protected]

다음과 같이 설정합니다.

[plugin.metrics.accesslog]
command = "/path/to/mackerel-plugin-ltsv-accesslog -request-time-key=reqtime -status-key=status /path/to/access.log"

위에서 설명한 대로 이 플러그인을 사용하면 요청 시간과 상태 코드 Key를 선택할 수 있습니다.
로그 양식의 자유도가 금방 높아졌기 때문에 나는 개인적으로 매우 편리하다고 생각한다.

[옵션] plugen-registry로 Pull Request 보내기

다른 사용자가 작성한 플러그인을 쉽게 찾을 수 있도록 Pull Request를 공식 플러그인 레지스트리에 제출합니다.plugins/ 아래에 <プラグイン名>.json 다음 내용의 파일을 만듭니다.

{
    "source": "nashiox/mackerel-plugin-ltsv-accesslog",
    "description": "LTSV Accesslog custom metrics plugin"
}

그런 다음 Pull Request를 보내고 병합하면 완료됩니다.

총결산

이번에 우리는 실제 플러그인 제작부터 제3자 플러그인 발표까지 설치 기능을 활용했다.
지금까지는 플러그인 설치의 번거로움을 줄이기 위해 맥커리어-agent-pluguins 등에 통합해야 했다. 비록 난이도가 높지만 내가 만든 플러그인 설치 기능이 정식으로 제공되었기 때문에 플러그인 제작의 난이도가 더욱 낮아졌다고 생각한다.
아직 공개되지 않은 자체 제작 플러그인도 있기 때문에 천천히 이쪽으로 다가가고 싶어요.
주제 외의 말을 하자면 이번에 제작되고 공개된 플러그인은plugen-registry에 Pull Request를 제출했지만 원본의 Mackerel-Plugin-accesslog와 너무 비슷해 통합되지 않았다.
이용자들이 쉽게 볼 수 있는 방법이 끊겼으니 인지도 향상에 꼭 협조해달라.