Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Snapshot status API returns different timing information than snapshot info API #43074

Closed
jen-huang opened this issue Jun 10, 2019 · 2 comments · Fixed by #43148
Closed

Snapshot status API returns different timing information than snapshot info API #43074

jen-huang opened this issue Jun 10, 2019 · 2 comments · Fixed by #43148
Assignees
Labels
>bug :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs

Comments

@jen-huang
Copy link

Snapshot info API returns the following stats for a given snapshot:

      "start_time" : "2019-06-10T23:02:36.637Z",
      "start_time_in_millis" : 1560207756637,
      "end_time" : "2019-06-10T23:02:37.040Z",
      "end_time_in_millis" : 1560207757040,
      "duration_in_millis" : 403,

Snapshot status API returns the following overall stats for the same snapshot:

        "start_time_in_millis" : 1560207756712,
        "time_in_millis" : 290,

Note that the start_time_in_millis values are different. The overall duration is also different, if time_in_millis is meant to represent the same duration as duration_in_millis.

I'm not sure if this is a bug or expected behavior. If it is expected, the difference should be documented more clearly.

Full request and responses

# GET /_snapshot/my-backups/snapshot_3
{
  "snapshots" : [
    {
      "snapshot" : "snapshot_3",
      "uuid" : "e450-h_FSjuTKaTNFqaZAQ",
      "version_id" : 8000099,
      "version" : "8.0.0",
      "indices" : [
        ".kibana_1",
        ".kibana_task_manager",
        ".security-7"
      ],
      "include_global_state" : true,
      "state" : "SUCCESS",
      "start_time" : "2019-06-10T23:02:36.637Z",
      "start_time_in_millis" : 1560207756637,
      "end_time" : "2019-06-10T23:02:37.040Z",
      "end_time_in_millis" : 1560207757040,
      "duration_in_millis" : 403,
      "failures" : [ ],
      "shards" : {
        "total" : 3,
        "failed" : 0,
        "successful" : 3
      }
    }
  ]
}


# GET /_snapshot/my-backups/snapshot_3/_status
{
  "snapshots" : [
    {
      "snapshot" : "snapshot_3",
      "repository" : "my-backups",
      "uuid" : "e450-h_FSjuTKaTNFqaZAQ",
      "state" : "SUCCESS",
      "include_global_state" : true,
      "shards_stats" : {
        "initializing" : 0,
        "started" : 0,
        "finalizing" : 0,
        "done" : 3,
        "failed" : 0,
        "total" : 3
      },
      "stats" : {
        "incremental" : {
          "file_count" : 22,
          "size_in_bytes" : 26378
        },
        "total" : {
          "file_count" : 67,
          "size_in_bytes" : 107766
        },
        "start_time_in_millis" : 1560207756712,
        "time_in_millis" : 290
      },
      "indices" : {
        ".kibana_task_manager" : {
          "shards_stats" : {
            "initializing" : 0,
            "started" : 0,
            "finalizing" : 0,
            "done" : 1,
            "failed" : 0,
            "total" : 1
          },
          "stats" : {
            "incremental" : {
              "file_count" : 0,
              "size_in_bytes" : 0
            },
            "total" : {
              "file_count" : 7,
              "size_in_bytes" : 13074
            },
            "start_time_in_millis" : 1560207756712,
            "time_in_millis" : 11
          },
          "shards" : {
            "0" : {
              "stage" : "DONE",
              "stats" : {
                "incremental" : {
                  "file_count" : 0,
                  "size_in_bytes" : 0
                },
                "total" : {
                  "file_count" : 7,
                  "size_in_bytes" : 13074
                },
                "start_time_in_millis" : 1560207756712,
                "time_in_millis" : 11
              }
            }
          }
        },
        ".security-7" : {
          "shards_stats" : {
            "initializing" : 0,
            "started" : 0,
            "finalizing" : 0,
            "done" : 1,
            "failed" : 0,
            "total" : 1
          },
          "stats" : {
            "incremental" : {
              "file_count" : 0,
              "size_in_bytes" : 0
            },
            "total" : {
              "file_count" : 35,
              "size_in_bytes" : 59988
            },
            "start_time_in_millis" : 1560207756712,
            "time_in_millis" : 36
          },
          "shards" : {
            "0" : {
              "stage" : "DONE",
              "stats" : {
                "incremental" : {
                  "file_count" : 0,
                  "size_in_bytes" : 0
                },
                "total" : {
                  "file_count" : 35,
                  "size_in_bytes" : 59988
                },
                "start_time_in_millis" : 1560207756712,
                "time_in_millis" : 36
              }
            }
          }
        },
        ".kibana_1" : {
          "shards_stats" : {
            "initializing" : 0,
            "started" : 0,
            "finalizing" : 0,
            "done" : 1,
            "failed" : 0,
            "total" : 1
          },
          "stats" : {
            "incremental" : {
              "file_count" : 22,
              "size_in_bytes" : 26378
            },
            "total" : {
              "file_count" : 25,
              "size_in_bytes" : 34704
            },
            "start_time_in_millis" : 1560207756844,
            "time_in_millis" : 158
          },
          "shards" : {
            "0" : {
              "stage" : "DONE",
              "stats" : {
                "incremental" : {
                  "file_count" : 22,
                  "size_in_bytes" : 26378
                },
                "total" : {
                  "file_count" : 25,
                  "size_in_bytes" : 34704
                },
                "start_time_in_millis" : 1560207756844,
                "time_in_millis" : 158
              }
            }
          }
        }
      }
    }
  ]
}

@jen-huang jen-huang added the :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs label Jun 10, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@original-brownbear original-brownbear self-assigned this Jun 11, 2019
@original-brownbear original-brownbear removed their assignment Jun 11, 2019
@original-brownbear
Copy link
Member

This is indeed a little strange. For the snapshot status API we return a serialized org.elasticsearch.action.admin.cluster.snapshots.status.SnapshotStatus which calculates the timings from the individual shard stats.
On the other hand, for the snapshot info API we return a SnapshotInfo which has the concrete start time stored in it. I think we should simply make the snapshot status API load the SnapshotInfo from the repo as well and use that instead of a calculation form the shard stats for determining the timings.

@original-brownbear original-brownbear self-assigned this Jun 12, 2019
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this issue Jun 12, 2019
* We don't have to calculate the start and end times form the shards for the status API, we have the start time available from the CS or the `SnapshotInfo` in the repo and can either take the end time form the `SnapshotInfo` or
take the most recent time from the shard stats for in progress snapshots
* Closes elastic#43074
original-brownbear added a commit that referenced this issue Jul 5, 2019
* We don't have to calculate the start and end times form the shards for the status API, we have the start time available from the CS or the `SnapshotInfo` in the repo and can either take the end time form the `SnapshotInfo` or
take the most recent time from the shard stats for in progress snapshots
* Closes #43074
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this issue Jul 12, 2019
* We don't have to calculate the start and end times form the shards for the status API, we have the start time available from the CS or the `SnapshotInfo` in the repo and can either take the end time form the `SnapshotInfo` or
take the most recent time from the shard stats for in progress snapshots
* Closes elastic#43074
original-brownbear added a commit that referenced this issue Jul 12, 2019
* We don't have to calculate the start and end times form the shards for the status API, we have the start time available from the CS or the `SnapshotInfo` in the repo and can either take the end time form the `SnapshotInfo` or
take the most recent time from the shard stats for in progress snapshots
* Closes #43074
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants