문제 해결 Mattermost 이슈

plans-img 모든 플랜 에서 사용 가능

deployment-img self-hosted 배포판

이 문서는 일반적인 문제 해결 문제 및 기술을 요약합니다.

경험 중인 오류 또는 문제 유형에 따라 아래 섹션을 참조하여 문제 해결 가이드를 확인하십시오. 새로운 사용자인 경우 설치 단계를 다시 확인하여 프로세스를 확인하는 것이 도움이 될 수 있습니다.

만약 Mattermost 제품에 유료 구독 (예: Mattermost Professional 또는 Mattermost Enterprise )을 가지고 있다면, 온라인 지원 포털을 통해 지원 티켓을 열 수 있습니다., via our online support portal .

또한, 모든 Mattermost 사용자를 위해 문제 해결 포럼커뮤니티 서버 에서 부터 부터 동료 지원을 받을 수 있습니다.

중요 사항

  • Mattermost 데이터베이스를 직접 조작하지 마십시오. Mattermost는 데이터 무결성이 손상되면 작동을 중지하도록 설계되었습니다.

  • 데이터베이스의 모든 조작은 내장된 명령 줄 도구를 사용하여 수행해야 합니다.

  • 작업 시스템의 단계별 설치 가이드로 시작하십시오.

배포 문제 해결

도커 배포

M1 Mac에서 Docker를 사용하여 Mattermost 서버를 배포하고 도커 컨테이너에서 권한 문제를 겪고있는 경우, 해당 디렉터리를 다시 생성하고 권한을 설정하십시오 , 그런 다음 다음 명령을 건너뛰십시오.:

sudo chown -R 2000:2000 ./volumes/app/mattermost

M1 시스템에서는 이 권한 변경으로 인해 배포가 작동을 중지하므로 이러한 단계를 모두 건너 뛰는 것이 좋습니다.

일반적으로 Docker를 사용하여 배포하는 중 문제가 발생하는 경우, docker 데몬이 활성화되어 있는지 확인하십시오:

sudo systemctl enable --now docker

Mattermost 배포에 대한 모든 데이터와 설정을 삭제하려면:

sudo rm -rf ./volumes

Postgres 문제

.env 파일에서 Postgres 사용자 이름 또는 비밀번호 (권장 사항)을 변경할 수 있습니다.

TLS 및 NGINX 문제

NGINX의 TLS 인증서 및 키를 구성하는 자세한 가이드는 이 리포지터리의 문서 를 참조하십시오.

Mattermost의 다른 버전 설치

  1. 배포를 중지하십시오.

  2. git pull 을 실행하여 리포지터리의 최신 변경 사항을 가져옵니다. env.example 변경 사항에 유의하십시오.

  3. .env 파일에서 MATTERMOST_IMAGE_TAG 를 조정하여 원하는 enterprise 또는 team 이미지 버전을 가리키십시오.

  4. Mattermost를 다시 배포하십시오.

mattermost-docker 로부터 업그레이드


일반적인 문제 해결

다음 제안 중 일부는 직접 수행할 수 있으며, 다른 제안은 네트워크 관리자의 상담이 필요할 수 있습니다.

Mattermost 로그 검토

Mattermost의 로그를 확인하고 문제 해결에 사용할 수 있습니다. 이러한 단계는 시스템 관리자 권한 을 가지고 있다고 가정합니다.

Mattermost 서버 로그

  • 로그 파일이 생성되는지 확인하십시오: System Console > Environment > Logging 으로 이동하여 Output logs to filetrue 로 설정되었는지 확인하십시오.

  • System Console > Environment > Logging > File Log Directory 에서 로그 파일의 경로를 확인할 수 있습니다.

생성된 서버 로그 파일은 mattermost.log 이라고 하며 표준 텍스트 에디터로 열거나 직접 공유할 수 있습니다.

Note

더 완전한 로그를 얻으려면 System Console > Environment > Logging 으로 이동하여 File Log LevelDEBUG 로 설정하고 문제를 다시 발생시킨 후 로그를 기록하십시오. 문제 해결 후 디스크 공간을 절약하기 위해 파일 로그 수준을 INFO 로 되돌리는 것이 중요합니다.

파일 시스템 액세스가 불가능한 경우 System Console > Reporting > Server Logs 으로 이동하여 현재 시스템 로그를 찾아 파일로 복사할 수 있습니다.

여기 에서 로깅 설정에 대해 더 많이 찾아볼 수 있습니다.

Mattermost 데스크톱 앱 로그

데스크톱 앱 로그 파일은 사용자 디렉터리에서 찾을 수 있습니다.

  • Windows: %userprofile%\AppData\Roaming\Mattermost\logs

  • Linux: ~/.local/share/Mattermost/logs 또는 ~/.config/Mattermost/logs

  • MacOS: ~/Library/Logs/Mattermost (DMG 설치) 또는 ~Library/Containers/Mattermost.Desktop/Data/Library/Logs/Mattermost (Appstore 설치)

Mattermost 브라우저 앱 로그

브라우저 기반 앱은 추가 로그 파일을 생성하지 않습니다. 앱을 디버깅해야하는 경우 브라우저에 통합된 개발 도구를 사용하여 작업 기록을 확인하십시오.

Mattermost 푸시 알림 서비스 로그

Mattermost 푸시 알림 서비스에 대한 로깅은 시스템 로그 기록을 통해 처리되며 /var/log/syslog 에 추가됩니다.

Mattermost 환경 검토

오류/문제 발생 전 사건을 제거하기 위해 타임라인을 작성하십시오. 예를 들어 방화벽을 최근에 다시 구성했으며 이제 연결 문제가 발생하는 경우 설정을 검토하거나 문제 해결을 위해 롤백하는 것이 문제 해결에 도움이 될 수 있습니다.

  • 문제가 발생한 후 정상 작동 기간이 있었다면 환경에서 무엇이 변경되었나요?
    • 클라이언트, 호스트 또는 서버가 업그레이드되었나요?

    • 운영 체제 업데이트가 적용되었나요?

    • 네트워크 환경이 변경되었나요? 예를 들어, 서버가 이동되었거나 도메인이 이동되었나요?

    • 시스템 (클라이언트 또는 서버)이 최근에 실패하거나 비정상적으로 종료되었나요?

  • 영향을 받는 사용자 수
    • 해당 문제가 사용자 중 한 명, 몇 명 또는 모든 사용자에게 영향을 주나요?

    • 문제가 최근에 환경에 추가된 사용자, 즉 새 직원과 같은 사용자에게만 발생하나요?

    • 영향을 받는 사용자와 영향을 받지 않는 사용자 사이에 차이가 있나요?

또한 온라인에서 오류 메시지를 검색할 수 있습니다. 포럼 에서 기존의 해결책을 찾아 적용할 수 있습니다.

다른 서버에 연결

  1. https://community.mattermost.com 에서 계정을 생성하십시오.

  2. 모바일 애플리케이션을 삭제하고 다시 설치하세요.

  3. 모바일 앱에서 서버 URL인 https://community.mattermost.com을 입력한 다음 로그인 자격 증명을 입력하여 연결이 작동하는지 테스트하세요.

다른 장치로 연결

  • 다른 모바일 장치가 있는 경우 해당 장치로 연결하여 문제가 여전히 재현되는지 확인하세요.

  • 다른 장치를 사용할 수 없는 경우 팀원들에게 동일한 문제가 있는지 확인하세요.

Self-hosted 배포에 대한 지원 티켓 열기

Mattermost 오퍼링에 대한 유료 구독 </about/editions-and-offerings.html>을 보유하고 있다면, Mattermost Professional 또는 Mattermost Enterprise 와 같은 경우 온라인 지원 포털 <https://support.mattermost.com/hc/en-us/requests/new>를 통해 지원 티켓을 열 권리가 있습니다.

유료 구독의 일환으로 지원 티켓을 열 때, 중요한 것은 가능한 한 많은 정보를 제때에 제공하는 것입니다. 어떤 정보가 관련되는지 파악하는 것이 혼란스러울 수 있습니다. 우리는 C.L.U.E.S. 라는 단어를 사용하여 무엇이 필요한지 기억합니다:

  • 구성 (Configurations)

  • 로그 (Logs)

  • 영향을 받는 사용자 (Users affected)

  • 환경 (Environment)

  • 재현 방법 (Steps to reproduce)

C.L.U.E.S.는 귀하의 문제를 명확히 하는 모든 정보를 대표합니다. 이러한 세부 사항이 있으면 문제의 원인을 찾기 시작할 수 있으며, 그것이 간단한 구성 변경이든 제품 버그를 수정하는데 가능한 많은 시간을 보낼 수 있도록 개발자들에게 문제를 에스컬레이션해주는 데 도움이 됩니다.

정보 제공에 대한 일반 지침

저희에게 진단 데이터를 제공할 때는 다음 지침을 따르세요:

  • 제공하는 파일이 몇 줄이 아니라 가능한 완전한지 확인하십시오. 완전한 로그 파일과 구성은 저희에게 중요한 맥락을 제공합니다.

  • 구성 및 로그 파일을 스크린샷보다는 평문 형식으로 제공하십시오. 이러한 형식은 스크린샷보다 저희가 검색하기가 훨씬 쉽습니다.

  • 특수 문자가 구성 오류의 일반적인 원인이기 때문에 사용자명, 비밀번호, LDAP 그룹을 제거하고 해당 세부 정보를 포함하는 예제 문자열로 치환하십시오.

  • 예기치 않은 제품 동작의 스크린샷이나 화면 녹화를 제공하여 사용자가 정확히 무엇을 보는지 알 수 있도록 하십시오.

구성 (Configuration)

왜 구성 데이터가 필요한가

리눅스 시스템에서 설정은 일반적으로 구성 파일에 저장됩니다. 많은 문제는 구성 설정을 활성화하거나 비활성화함으로써 해결할 수 있습니다. 해결책을 찾기 위해 가능한 한 완전한 시스템 설정에 대한 정보가 필요합니다. 또한 이는 버그를 재현하여 개발자들이 이를 수정할 수 있도록 도울 수 있습니다.

구성 데이터에는 다음이 포함됩니다(다만, 이에 국한되지는 않음):

  • Mattermost의 config.json 파일.

  • Reverse proxy(예: NGINX, HAProxy, AWS)의 구성.

  • 데이터베이스 구성.

  • SAML 인증과 관련된 문제인 경우 SAML 구성. Mattermost 서비스의 구성은 SAML IdP에 있습니다.

  • Mattermost가 연결하는 다른 시스템 또는 사용자와 Mattermost 서버 사이에 존재하는 다른 시스템.

구성 데이터에 대한 액세스 방법

Mattermost 구성

Mattermost 구성은 보통 /opt/mattermost/config/config.json 에 저장됩니다. Mattermost 구성을 데이터베이스로 마이그레이션한 경우에는 mmctl 을 사용하거나 다음 데이터베이스 쿼리를 실행하여 구성을 얻을 수 있습니다:

  SELECT Value FROM Configurations WHERE Active = 1;

**Reverse Proxy 구성**

NGINX는 일반적으로 구성을 두 부분으로 분리합니다: /etc/nginx/nginx.conf 에 있는 주 서버 구성 및 가상 서버 구성. Ubuntu의 경우 후자는 /etc/nginx/sites-available 에 저장됩니다. 이러한 구성 파일을 둘 다 제공하는 것이 도움이 되지만 후자를 제공하는 것이 더 중요합니다.

SAML 구성

SAML 로그인과 관련된 문제가 있는 경우, SAML 공급자의 Mattermost 서비스에 대한 전체 구성을 확인해야 합니다. Mattermost 서비스의 구성은 SAML IdP에 있습니다. 설정 설명서에서와 유사한 스크린샷을 제공하는 것이 충분합니다. 대부분의 SAML 공급자는 웹 인터페이스를 사용하여 구성되기 때문입니다.

LDAP 구성

LDAP 관리자는 다음과 같은 Mattermost LDAP 설정의 올바른 값을 확인해야 합니다:

  • LDAP 서버 호스트명.

  • LDAP 연결 포트, 보안 및 인증서.

  • BaseDN, 바인드 사용자 이름 및 바인드 비밀번호.

  • 사용자, 그룹, 게스트 및 관리자 필터.

  • 디스플레이 속성.

이러한 정보는 LDAP 서버에서 텍스트 파일 또는 스크린샷으로 제공할 수 있습니다.

기타 구성

모바일에서 문제가 발생하고 서버에 연결하기 위해 MDM이나 VPN을 사용하는 경우, 문제를 진단하기 위해서 해당 구성이 필요합니다. 외부 시스템의 시스템 관리자는 해당 구성을 제공할 수 있어야 합니다.

로그 (Logs)

로그가 필요한 이유

거의 모든 컴퓨터 시스템에는 응용 프로그램이 실행될 때 발생하는 오류와 응용 프로그램 동작의 로그가 있습니다. 응용 프로그램이 실행될 때 무슨 일이 일어나는지 보여주는 에러 로그는 문제를 진단할 때 매우 유용합니다. 그러나 가능한 한 완전한 경우에만 유용합니다.

사용 가능한 로그

Mattermost

Mattermost에는 일반 메시지용 로그와 알림 관련 메시지 용 로그 두 개가 있습니다. 다음 경로에서 찾을 수 있습니다:

  • /opt/mattermost/logs/mattermost.log

  • /opt/mattermost/logs/notification.log

프록시

이러한 위치는 프록시 구성에 따라 다를 수 있지만, 로그를 찾아보기 좋은 곳은 /var/log 입니다. 프록시 관리자는 로그를 찾는 것에 도움을 줄 수 있어야 합니다.

데이터베이스

PostgreSQL 및 MySQL에는 서로 다른 로그가 있으며, 위치는 구성에 따라 다릅니다. 데이터베이스 연결과 관련된 문제인 경우 데이터베이스 설명서를 확인하여 로그 위치를 찾으십시오.

SAML, LDAP 및 기타 시스템

귀하 조직의 시스템 관리자는 이러한 로그를 찾을 수 있어야 합니다.

로그 액세스 방법

Mattermost

로그에서 가장 많은 정보를 얻을 수 있도록 디버그 로그 기록이 활성화되어 있는지 확인하십시오. 이를 위해서는 시스템 콘솔 > 환경 > 로깅 으로 이동하여 콘솔 및 파일 로그 수준을 DEBUG 로 설정하십시오.

행동이 알려진 시간 또는 날짜에서 시작된 경우 다음과 같이 journalctl 을 사용하여 로그를 가져옵니다:

sudo journalctl -u mattermost --since "2020-08-23 17:15:00" > mattermost_journalctl.log

2020-08-23 17:15:00를 행동이 시작된 날짜와 시간으로 대체하십시오. 서버 시간을 얻으려면 date 명령을 사용하십시오. 만일 생성된 로그 파일이 너무 크다면 다음 명령을 사용하여 해당 로그를 압축하십시오:

tar -czf /tmp/mattermost.log.tgz

압축된 로그는 서버에서 /tmp/mattermost.log.tgz 에 위치합니다.

압축된 파일 크기가 여전히 너무 크다면, 다음 명령을 사용하여 압축 파일을 두 개 이상의 20MB 파일로 분할하십시오:

mkdir -p /tmp/mattermost-logs
cd /tmp/mattermost-logs
tar czf - /opt/mattermost/logs/mattermost.log | split -b 20m - mattermost.log.tgz.

압축된 파일은 서버의 /tmp/mattermost-logs 에 있으며, mattermost.log.tgz.aa , mattermost.log.tgz.ab , 등으로 명명될 것입니다. 이 파일들을 서버로부터 복사하기 위해 SSH/SFTP를 지원하는 파일 전송 클라이언트인 Cyberduck와 같은 것을 사용하세요.

Elasticsearch, LDAP 또는 데이터베이스에 문제가 있는 경우에는, 각각의 설정에서 Tracetrue 로 설정하여 config.json 에서 추적 로그를 활성화할 수 있습니다. 이를 DEBUG 레벨 파일 로그 출력과 결합하면 매우 큰 로그 파일이 생성되므로 동작을 복제할 시간만큼만 추적 로깅을 유지하십시오. 결과적으로 생성된 로그에는 사용자 데이터를 포함한 많은 민감한 데이터가 포함되므로 공유하기 전에 완전히 필터링하십시오.

시스템 로그

기타 시스템의 로그 파일 위치는 다양하지만, Mattermost 서버의 모든 프로세스에 대한 로그를 가져오는 좋은 방법은 다음과 같이 journalctl 을 사용하는 것입니다:

 sudo journalctl --since "2020-08-23 17:15:00" > mattermost_journalctl.log

``2020-08-23 17:15:00``    서버와 관련된 날짜와 시간으로 바꿔서 오류가 발생한 시간을 나타내십시오. 동일한 타임스탬프 형식을 사용하여  시간 사이의 로그를 얻으려면   ``--until``    사용할  있습니다:
sudo journalctl --since "2020-08-23 17:15:00" --until "2020-08-23 16:30:00" > mattermost_journalctl.log

영향을 받는 사용자

필요한 이유

Mattermost 서버는 혼돈스러운 곳입니다. 사용자가 여러 팀에 걸쳐 수십 개의 채널에 있을 때마다 수천 개의 게시물, 웹소켓 액션, 웹훅 호출 등이 발생합니다. 어떤 사용자가 문제를 겪고 있는지 알면 모든 이 정보들 속에서 근본 원인을 찾는 데 도움이 됩니다.

포함해야 할 정보

이는 예기치 않은 동작을 신고하는 최종 사용자들이 공통으로 가지고 있는 것에 대한 상세한 설명이어야 합니다. 이에는 (하지만 이에 한정되지 않음):

  • 다이렉트 및 그룹 메시지를 포함한 팀 및 채널 멤버십.

  • 인증 방법.

  • 클라이언트 운영 체제 및 응용 프로그램 버전.

  • 사용자가 Mattermost 서버에 어떻게 연결하는지.

  • 가입한 시기, 최근 로그인 정보 변경 여부, LDAP를 통해 동기화되는지 여부 등 사용자들이 공통적으로 가지고 있는 다른 것들.

상담원을 위한 참고 사항: 이 정보가 또한 필요합니다:

  • 고객명

  • 고객 연락처

  • 고객 라이선스, 예: 엔터프라이즈/프로페셔널

  • 고객 계층

환경

Mattermost 서버가 있는 환경에 따라 잠재적인 문제에 영향을 미치게 됩니다. 예를 들어, 잘못 구성된 프록시 서버는 Mattermost에 문제가 없더라도 사용자의 연결을 방해할 수 있습니다.

포함해야 할 정보

이에 기인하여, Mattermost 서버가 작동하는 서버 및 네트워크의 전체적인 상황을 파악하는 것은 문제를 해결하는 데 있어 핵심 요소입니다. 이에는 (하지만 이에 한정되지 않음):

  • Mattermost 버전 (예: 7.3.0, 7.8.3)

  • 서버 운영 체제 및 버전 (예: RHEL7, Ubuntu 18.04)

  • Docker 또는 Kubernetes와 같은 오케스트레이션/자동화 사용 여부

  • 리버스 프록시 및 버전 (예: NGINX 1.16)

  • 데이터베이스 유형 및 버전 (예: PostgreSQL 12.4)

  • SAML 제공자 (예: Windows Server 2012 Active Directory, Okta, KeyCloak)

  • LDAP 제공자 (예: Windows Server 2016 Active Directory, Okta, OpenLDAP)

  • Mattermost 서버가 통과하는 네트워크에 있는 프록시 또는 VPN의 유형 및 버전

환경을 설명할 때 가능한 구체적으로 하십시오. 연결이 거부되었습니다 와 같은 오류를 보고하는 경우 네트워크에서 내부 또는 외부로 작용하는 방화벽이나 필터링 프록시도 포함해야 합니다.

예시

Mattermost 서버

  • 외부 호스트명: mattermost.example.com

  • 내부 호스트명: mattermost.lan

  • Mattermost v7.3.0

  • Zoom 플러그인 v1.4.1

  • NGINX v1.18.0

데이터베이스 서버

  • 내부 호스트명: postgresql.lan

  • PostgreSQL v11

  • LDAP 제공자 - 192.168.1.102

  • 내부 호스트명: ldap.lan

  • OpenLDAP 2.4.54 (도커 컨테이너)

Mattermost 서버

  • 호스트명: mm1.local.lan, mm2.local.lan, mm3.local.lan, mm4.local.lan

Mattermost 서버 버전

  • mm1-3: 5.25.4

  • mm4: 5.21.0

프록시 서버

  • 외부 호스트명: mattermost.example.com

  • 내부 호스트명: proxy.local.lan

  • NGINX v1.16.0

데이터베이스 서버

  • 호스트명: db1.local.lan, db2.local.lan, db3.local.lan

  • 프라이머리: db1.local.lan

  • 읽기 전용: db2.local.lan, db3.local.lan

  • PostgreSQL v11

Elasticsearch 서버

  • 호스트명: elastic.local.lan

  • Elasticsearch 7.9와 이러한 플러그인들

  • analysis-icu

재현 방법

무엇인지

행동이 특정 조작을 통해 일어나는 경우, 이러한 행동을 재현하기 위한 상세한 단계를 제공하면 올바른 버그를 찾아 수정하는 데 도움이 됩니다. 이 세부 정보들은 가능한 한 기술적으로 작성되어야 하지만 그 행동을 화면 캡쳐하거나 화면 녹화한 것보다 좋습니다.

이러한 세부 정보를 제공하는 방법

macOS

화면 녹화 도구를 여는 데 :kbd: :kbd: :kbd: 5 를 누르고 녹화할 화면 영역을 선택합니다. 화면 캡처를 찍으려면 :kbd: :kbd: :kbd: 4 를 누르고 캡처할 영역을 선택합니다. 기본적으로 화면 캡처 파일은 바탕화면에 저장됩니다.

Windows

화면 캡처를 찍기 위해 :kbd: Ctrl :kbd: Shift :kbd: S 를 눌러 캡처 도구를 엽니다. 화면 녹화를 하려면 OBS 와 같은 제3자 소프트웨어를 설치해야 합니다.

iOS

아이폰에서 화면 캡처 또는 화면 녹화는 여기 를 참조하십시오.

Android

Android 기기 에서 화면 캡처 또는 화면 녹화를 할 수 있습니다.

부록

모바일 문제에 대한 참고 사항

모바일 앱에 디버그 모드가 없기 때문에 사용자 데이터에서 발생하는 문제를 진단하기 위해서는 Charles나 mitmproxy와 같은 프록시가 필요합니다. 이러한 도구들은 클라이언트에서의 트래픽을 가로채서 기록하고, 그것을 다시 재현할 수 있게 해줍니다. 이를 설정하는 데 도움이 필요하면 고객 엔지니어에게 연락하십시오.

SAML 로그인 문제

SAML 로그인에 문제가 있다면 중요한 맥락 중 하나는 SAML 로그인 플로우입니다. 이 플로우에는 헤더와 인증 정보가 포함되어 있어 문제를 쉽게 해결할 수 있는 문제를 드러낼 수 있습니다. SAML 인증에 문제가 있는 경우 SAML 로그인 플로우를 확인하려면 다음 지침을 따르세요.

키 및 인증서 확인

키 및 인증서 파일은 절대로 공유해서는 안 됩니다. 그러나 오류가 키 또는 인증서의 형식에 문제가 있다는 것을 나타내는 경우 다음 명령을 실행하여 키 및 인증서의 형식을 검증해야 합니다.

cat -A /path/to/key-or.cert

출력은 다음 기준을 정확히 준수해야 합니다:

  • -----BEGIN CERTIFICATE-----$ 로 시작해야 합니다.

  • 모든 줄은 $ 로 끝나야 합니다. ^M$ 으로 끝나는 경우에는 dos2unix 를 사용하여 UNIX 줄 끝으로 변환해야 합니다.

  • -----END CERTIFICATE-----$ 로 끝나야 합니다.