AWS IoT rule - timestamp for Elasticsearch












0















Have a bunch of IoT devices (ESP32) which publish a JSON object to things/THING_NAME/log for general debugging (to be extended into other topics with values in the future).



Here is the IoT rule which kind of works.



{
"sql": "SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS timestamp, topic(2) AS deviceId FROM 'things/+/stdout'",
"ruleDisabled": false,
"awsIotSqlVersion": "2016-03-23",
"actions": [
{
"elasticsearch": {
"roleArn": "arn:aws:iam::xxx:role/iot-es-action-role",
"endpoint": "https://xxxx.eu-west-1.es.amazonaws.com",
"index": "devices",
"type": "device",
"id": "${newuuid()}"
}
}
]
}


I'm not sure how to set @timestamp inside Elasticsearch to allow time based searches.



Maybe I'm going about this all wrong, but it almost works!










share|improve this question





























    0















    Have a bunch of IoT devices (ESP32) which publish a JSON object to things/THING_NAME/log for general debugging (to be extended into other topics with values in the future).



    Here is the IoT rule which kind of works.



    {
    "sql": "SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS timestamp, topic(2) AS deviceId FROM 'things/+/stdout'",
    "ruleDisabled": false,
    "awsIotSqlVersion": "2016-03-23",
    "actions": [
    {
    "elasticsearch": {
    "roleArn": "arn:aws:iam::xxx:role/iot-es-action-role",
    "endpoint": "https://xxxx.eu-west-1.es.amazonaws.com",
    "index": "devices",
    "type": "device",
    "id": "${newuuid()}"
    }
    }
    ]
    }


    I'm not sure how to set @timestamp inside Elasticsearch to allow time based searches.



    Maybe I'm going about this all wrong, but it almost works!










    share|improve this question



























      0












      0








      0








      Have a bunch of IoT devices (ESP32) which publish a JSON object to things/THING_NAME/log for general debugging (to be extended into other topics with values in the future).



      Here is the IoT rule which kind of works.



      {
      "sql": "SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS timestamp, topic(2) AS deviceId FROM 'things/+/stdout'",
      "ruleDisabled": false,
      "awsIotSqlVersion": "2016-03-23",
      "actions": [
      {
      "elasticsearch": {
      "roleArn": "arn:aws:iam::xxx:role/iot-es-action-role",
      "endpoint": "https://xxxx.eu-west-1.es.amazonaws.com",
      "index": "devices",
      "type": "device",
      "id": "${newuuid()}"
      }
      }
      ]
      }


      I'm not sure how to set @timestamp inside Elasticsearch to allow time based searches.



      Maybe I'm going about this all wrong, but it almost works!










      share|improve this question
















      Have a bunch of IoT devices (ESP32) which publish a JSON object to things/THING_NAME/log for general debugging (to be extended into other topics with values in the future).



      Here is the IoT rule which kind of works.



      {
      "sql": "SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS timestamp, topic(2) AS deviceId FROM 'things/+/stdout'",
      "ruleDisabled": false,
      "awsIotSqlVersion": "2016-03-23",
      "actions": [
      {
      "elasticsearch": {
      "roleArn": "arn:aws:iam::xxx:role/iot-es-action-role",
      "endpoint": "https://xxxx.eu-west-1.es.amazonaws.com",
      "index": "devices",
      "type": "device",
      "id": "${newuuid()}"
      }
      }
      ]
      }


      I'm not sure how to set @timestamp inside Elasticsearch to allow time based searches.



      Maybe I'm going about this all wrong, but it almost works!







      amazon-web-services elasticsearch aws-iot






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 26 '18 at 21:39







      Nick

















      asked Nov 26 '18 at 21:17









      NickNick

      860719




      860719
























          1 Answer
          1






          active

          oldest

          votes


















          1














          @timestamp is just a convention as the @ prefix is the default prefix for Logstash generated fields. Because you are not using Logstash as a middleman between IoT and Elasticsearch, you don't have a default mapping for @timestamp.



          But basically, it is just a name, so call it what you want, the only thing that matters is that you declare it as a timestamp field in the mappings section of the Elasticsearch index.



          If for some reason you still need it to be called @timestamp, you can either SELECT it with that prefix right away in the AS section (might be an issue with IoT's sql restrictions, not sure):



          SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS @timestamp, topic(2) AS deviceId FROM 'things/+/stdout'


          Or you use the copy_to functionality when declaring you're mapping:



          PUT devices/device
          {
          "mappings": {
          "properties": {
          "timestamp": {
          "type": "date",
          "copy_to": "@timestamp"
          },
          "@timestamp": {
          "type": "date",
          }
          }
          }
          }





          share|improve this answer



















          • 1





            Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

            – Nick
            Nov 30 '18 at 15:14











          • Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

            – Chaos Monkey
            Dec 1 '18 at 12:17











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53489214%2faws-iot-rule-timestamp-for-elasticsearch%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1














          @timestamp is just a convention as the @ prefix is the default prefix for Logstash generated fields. Because you are not using Logstash as a middleman between IoT and Elasticsearch, you don't have a default mapping for @timestamp.



          But basically, it is just a name, so call it what you want, the only thing that matters is that you declare it as a timestamp field in the mappings section of the Elasticsearch index.



          If for some reason you still need it to be called @timestamp, you can either SELECT it with that prefix right away in the AS section (might be an issue with IoT's sql restrictions, not sure):



          SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS @timestamp, topic(2) AS deviceId FROM 'things/+/stdout'


          Or you use the copy_to functionality when declaring you're mapping:



          PUT devices/device
          {
          "mappings": {
          "properties": {
          "timestamp": {
          "type": "date",
          "copy_to": "@timestamp"
          },
          "@timestamp": {
          "type": "date",
          }
          }
          }
          }





          share|improve this answer



















          • 1





            Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

            – Nick
            Nov 30 '18 at 15:14











          • Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

            – Chaos Monkey
            Dec 1 '18 at 12:17
















          1














          @timestamp is just a convention as the @ prefix is the default prefix for Logstash generated fields. Because you are not using Logstash as a middleman between IoT and Elasticsearch, you don't have a default mapping for @timestamp.



          But basically, it is just a name, so call it what you want, the only thing that matters is that you declare it as a timestamp field in the mappings section of the Elasticsearch index.



          If for some reason you still need it to be called @timestamp, you can either SELECT it with that prefix right away in the AS section (might be an issue with IoT's sql restrictions, not sure):



          SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS @timestamp, topic(2) AS deviceId FROM 'things/+/stdout'


          Or you use the copy_to functionality when declaring you're mapping:



          PUT devices/device
          {
          "mappings": {
          "properties": {
          "timestamp": {
          "type": "date",
          "copy_to": "@timestamp"
          },
          "@timestamp": {
          "type": "date",
          }
          }
          }
          }





          share|improve this answer



















          • 1





            Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

            – Nick
            Nov 30 '18 at 15:14











          • Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

            – Chaos Monkey
            Dec 1 '18 at 12:17














          1












          1








          1







          @timestamp is just a convention as the @ prefix is the default prefix for Logstash generated fields. Because you are not using Logstash as a middleman between IoT and Elasticsearch, you don't have a default mapping for @timestamp.



          But basically, it is just a name, so call it what you want, the only thing that matters is that you declare it as a timestamp field in the mappings section of the Elasticsearch index.



          If for some reason you still need it to be called @timestamp, you can either SELECT it with that prefix right away in the AS section (might be an issue with IoT's sql restrictions, not sure):



          SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS @timestamp, topic(2) AS deviceId FROM 'things/+/stdout'


          Or you use the copy_to functionality when declaring you're mapping:



          PUT devices/device
          {
          "mappings": {
          "properties": {
          "timestamp": {
          "type": "date",
          "copy_to": "@timestamp"
          },
          "@timestamp": {
          "type": "date",
          }
          }
          }
          }





          share|improve this answer













          @timestamp is just a convention as the @ prefix is the default prefix for Logstash generated fields. Because you are not using Logstash as a middleman between IoT and Elasticsearch, you don't have a default mapping for @timestamp.



          But basically, it is just a name, so call it what you want, the only thing that matters is that you declare it as a timestamp field in the mappings section of the Elasticsearch index.



          If for some reason you still need it to be called @timestamp, you can either SELECT it with that prefix right away in the AS section (might be an issue with IoT's sql restrictions, not sure):



          SELECT *, parse_time("yyyy-mm-dd'T'hh:mm:ss", timestamp()) AS @timestamp, topic(2) AS deviceId FROM 'things/+/stdout'


          Or you use the copy_to functionality when declaring you're mapping:



          PUT devices/device
          {
          "mappings": {
          "properties": {
          "timestamp": {
          "type": "date",
          "copy_to": "@timestamp"
          },
          "@timestamp": {
          "type": "date",
          }
          }
          }
          }






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 30 '18 at 9:44









          Chaos MonkeyChaos Monkey

          452212




          452212








          • 1





            Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

            – Nick
            Nov 30 '18 at 15:14











          • Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

            – Chaos Monkey
            Dec 1 '18 at 12:17














          • 1





            Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

            – Nick
            Nov 30 '18 at 15:14











          • Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

            – Chaos Monkey
            Dec 1 '18 at 12:17








          1




          1





          Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

          – Nick
          Nov 30 '18 at 15:14





          Ah nice one I deleted the index and recreated it with timestamp.type = date and it's all working now. You can't put the @ in the IoT SQL SELECT no matter what quotes you wrap it in.

          – Nick
          Nov 30 '18 at 15:14













          Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

          – Chaos Monkey
          Dec 1 '18 at 12:17





          Yeah figured that they will probably ban certain types of characters. Well, at least you've got Elastic for the rescue. Good luck!

          – Chaos Monkey
          Dec 1 '18 at 12:17




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53489214%2faws-iot-rule-timestamp-for-elasticsearch%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

          Calculate evaluation metrics using cross_val_predict sklearn

          Insert data from modal to MySQL (multiple modal on website)