Kibana не показує жодних результатів на вкладці "Дізнатися"

Я налаштував elasticsearch та Kibana для індексації журналів нашого додатка (помилок). Проблема в тому, що Kibana не відображає жодних даних на вкладці "Відкрити".

Нинішня ситуація

• Elasticsearch працює і працює, відповідає API
• виконання запиту безпосередньо на Elasticsearch, як http://elasticserver.com:9200/applogs/_search?q=*повернення багатьох результатів (див. нижче, як виглядає один знайдений запис)
• Кібана працює і навіть знаходить applogsіндекс, виставлений Elasticsearch
• Кібана також показує правильні властивості та тип даних applogsдокументів
• Вкладка "Відкрити" не показує результатів ... навіть при встановленні періоду часу на пару років ...

Будь-які ідеї ??

Ось як Кібана бачить applogsіндекс :

Еластичний об'єкт результату пошукового запиту виглядає так:

{
_index: "applogs",
_type: "1",
_id: "AUxv8uxX6xaLDVAP5Zud",
_score: 1,
_source: {
   appUid: "esb.Idman_v4.getPerson",
   level: "trace",
   message: "WS stopwatch is at 111ms.",
   detail: "",
   url: "",
   user: "bla bla bla",
   additionalInfo: "some more info",
   timestamp: "2015-03-31T15:08:49"
 }
},

..і те, що я бачу на вкладці Discover :

Для людей , у яких є проблеми , як це:

Змініть часові рамки у верхньому правому куті.

За замовчуванням він відображає дані лише за останні 15 хв .

Я хотів залишити це як коментар, але, на жаль, я не можу дати моє дефіцитне репо для цього. Так як це було запропоновано @Ngeunpo, це те , як ви додаєте поле часу до індексу при створенні його: . Якщо ви не робили цього під час створення вашого індексу, я пропоную вам видалити цей індекс і відтворити його. Ім'я індексу logstash- * у gif є аналогічним вашим індексам applogs . У цьому випадку як часове поле додається поле @timestamp . Повідомте мене, якщо це спрацює.

EDIT: Ввічливість зображення: Цей чудовий посібник з налаштування ELK

Кібана не розуміє поле позначки часу , якщо формат неправильний. Мітка часу , яку ви вибрали, натиснувши ім'я поля часу під час налаштування шаблону індексу, має бути:

"timestamp":"2015-08-05 07:40:20.123"

тоді вам слід оновити своє відображення індексу таким чином:

curl -XPUT 'http://localhost:9200/applogs/1/_mapping' -d'
{
  "1": {
    "timestamp": {
      "enabled": true,
      "type": "date",
      "format": "yyyy-MM-dd HH:mm:ss.SSS",
      "store": true
    }
  }
}'

Дивіться це питання та відповідь

ОНОВЛЕННЯ

Якщо ви використовуєте ES 2.X, ви можете встановити , "format"щоб "epoch_millis"це подобається:

curl -XPUT 'http://localhost:9200/applogs/1/_mapping' -d'
{
  "1": {
    "timestamp": {
      "type": "date",
      "format": "epoch_millis",
      "store": true,
      "doc_values": true
    }
  }
}'

Спробуйте це: зніміть прапорець "Індекс містить події, засновані на часі", а потім вкажіть своє ім'я індексу, а потім поставте прапорець "Відкрити", чи містить він дані чи ні

У мене була та сама проблема, і це спрацювало для мене:

1. Видаліть індекс з вкладки Налаштування.
2. перезапустіть Kibana
3. потім повторно додайте у Налаштуваннях

Проблеми з часовими рядами, я впевнений, також можуть бути проблемою, але якщо на вкладці «Відкрити» насправді не відображаються поля, то у вас може бути така ж проблема, як у оригінального репортера та того, що я мав.

У мене була, мабуть, та сама проблема - я бачу дані на інформаційній панелі, але 0 результатів у Discover. Перехід до Менеджер> Індексна схема> Оновити кнопку списку поданих (кнопка зі значком оновлення) вирішив це для мене.

У мене була та сама проблема, і коментар @ tAn- допоміг мені її вирішити. Зміна поля дати на @timestamp зробила свою справу. Спасибі!

Наступним кроком має бути з’ясування того, що було неправильним у моєму власному полі дати.

У мене була та сама проблема, але зараз вона працює нормально. Проблема була в @timestamp. Насправді я завантажив файл, elasticsearchвикористовуючи, logstashтаким чином, він автоматично генерує поле @timestamp. Kibanaпорівняти діапазон часу з цією @ міткою часу, тобто коли відбулася фактична подія. Навіть якщо я kibanaскасую вибір опції «Індекс містить події, засновані на часі» на сторінці додавання нової сторінки шаблону індексу, автоматично враховуватиме поле @timestamp. kibanaна основі поля @timestamp працювало для мене. Ви також можете перевірити, додавши шаблон індексу без позначки часу та знявши прапорець "Індекс містить події, засновані на часі".kibanaсторінку Discover, і ви, швидше за все, отримаєте результат на сторінці Discover. Це всі мої спостереження, не впевнений, це рішення відповідає вашому випадку .. можете спробувати .. Я використовую ES 1.5x, logstash 1.5.1 та kibana 4.1.0

Я теж зазнав тієї ж помилки. Здебільшого це відбувається через часовий формат . По суті, переконайтеся, що у вас є дійсний часовий проміжок для ваших даних (верхній правий фільтр). У будь-якому випадку, у моєму випадку я використовував формат часу епохи для позначки часу, але це не спрацювало. Тож я замість цього змінився на epoch_millisec, і це спрацювало як шарм.

Підсумовуючи, переконайтесь, що Kibana може зрозуміти формат вашого часу та дати. За замовчуванням потрібно epoch_millisec , а не просто epoch.

У моїй ситуації все працювало раніше, і тоді я не міг бачити останні дані, починаючи з 1 лютого (насправді, міг би, якби озирнувся місяць назад). Виявляється, формат відображення для мого власного часового поля був неправильним. Мій формат відображення був YYYY-MM-DD'T'HH:mm:ss.SSSZ. Проблема полягала в тому, що DDінтерпретується як день року, і я хотів день місяця, який є dd. Зміна відображення та переіндексація вирішили проблему.

У мене була та сама проблема, тому, як показано в одному з рішень вище, я перейшов до налаштувань і видалив попередній індекс і створив новий за допомогою @timestamp.

Але це не вирішило проблеми. Отже, я вивчив проблему і побачив, що після розгортання в Кібану нічого не надходить.

Отже, я зайшов на сервер і побачив, що індекси пошкоджені. ТАК я просто зупинив logstash та elasticsearch на екземплярі / сервері та перезапустив службу. І Voila, він успішно перезапустив службу, і kibana повернувся.

ЧОМУ ЦЕ ВІДБИЛОСЯ?

Хтось міг різко зупинити сервер, що спричинило пошкодження індексів.