Event History cleared for maintenance

[beckwith]

This doesn’t make sense and needs clarification:

"Maintenance Details
Due to changes supporting new functionality, and the increasing growth of our platform, SmartThings has seen increased pressure on the database clusters which store activity data between Hubs, SmartApps, and devices.

To relieve this pressure, at 10:00AM PST / 1:00PM EST / 6:00PM GMT on January 22, 2016 we are adding additional database clusters to spread the load and allow for faster and more reliable data transfer. Unfortunately, while this will be a long-term improvement, it will clear the “Event History” in the SmartThings app.

As new events flow into the database clusters, the history will repopulate. There will be no downtime during this maintenance period.
Jan 21, 21:59 EST"

[btk (The fish is still dead.)]

Made sense to me. What sort of clarification are you looking for?

[keltymd (Matt)]

you may not be able to see some of your event history for a bit but it will come back. More clusters = better performance (god I hope)

[beckwith]

The week of event history? History will repopulate? What is this statement?

What is the “unfortunate” impact of cleared event history?

[beckwith]

So it will disappear for a while and come back?

[btk (The fish is still dead.)]

Yes. The way I read it, all of the existing event history will be lost in the move to the new clusters. As new events come in, they will be stored on these new clusters and will be visible in your event history.

The unfortunate impact is that we will lose our event history, but it will immediately start being repopulated with any new events that arrive.

[beckwith]

I agree it makes the most sense but repopulate makes it sound like it is putting back what is cleared out. Why use “re”?

Basically, the event history will not be transferred to the new clusters.

[kars85]

@beckwith

Unfortunately, while this will be a long-term improvement, it will clear the “Event History” in the SmartThings app.

Event history gets wiped…

@beckwith

As new events flow into the database clusters, the history will repopulate.

Any new events will repopulate (on the new DB cluster).

In all honesty, wiped event histories (i.e. logs) are pretty trivial given the issues lately. I don’t really have any need to look at event histories for something after the platform “fixes” are in place!

[Jnick (John)]

They worded everything correctly. Your event history is currently populated. After the database maintenance, all history will be lost. Once the maintenance finishes, the event history area will begin to repopulate with new events. It is repopulating because it was once populated, then it won’t be, then it will be again…seemed pretty clear to me…?

[btk (The fish is still dead.)]

If I had to guess what went down in the ST war room, it’d be that they determined moving to new database clusters was a solution to one or more of the current issues. Then they discussed how long it would take to properly migrate everyone’s event histories. Seconds after that they decided that whatever that amount of time was, it wasn’t worth keeping the platform in its current state and they should just do a clean cut-over.

[beckwith]

@Jnick

They worded everything correctly

I must be having a brain fart, because I had to read this over many times and still didn’t understand it.

I agree with @kars85 that I’m all for stability. Do what it takes.

[SBDOBRESCU (Bobby)]

Is not like Tim didn’t warn us that it’s coming…(they seem to just expanded a little)

Announcement: Changes to scheduler history in IDE

Hey guys and gals! I am writing this to let you all know that we have, for the time being, turned off schedule history in the IDE. We are currently re-evaluating how we can turn this back on, but in the meantime we need to turn it off to help offset the load on the platform. This is not all history but just the scheduler history. You will still be able to see when the app itself sends commands to devices using event and device logs. tl;dr - We are turning off the scheduler history for now with the plan to turn it back on when we can enhance this functionality while balancing for load/capacity issues. [image]

[Tyler]

@btk

Yes. The way I read it, all of the existing event history will be lost in the move to the new clusters. As new events come in, they will be stored on these new clusters and will be visible in your event history.

The unfortunate impact is that we will lose our event history, but it will immediately start being repopulated with any new events that arrive.

Yup! Sorry for the inconvenience everyone. This should end up helping with a lot of the issues that have been reported recently.

[bamarayne (Jason "The Enabler" as deemed so by @Smart)]

well, my question is why exactly are valuable server resources being wasted on this amount of even history anyway?

I don’t see a need for anything over 24 to 48 hours old. Take a screen shot if you want to store it local for later T/S. If not, it’s really not needed.

At least, it really not needed that much from our perspective, but the IT’s at ST definitely need it!

[slagle (Tim Slagle)]

Hey guys,

Just chiming in here. We’re doing this to alleviate a lot of the pressure that we see on the platform. Basically we are expanding the number of DB clusters we have. Unfortunately it wasn’t easily migratable (I know migratable isn’t a word lol).

This should really help a lot of things and is a step in the right direction. We can only ask for your patience as we grow thorough this.

[bamarayne (Jason "The Enabler" as deemed so by @Smart)]

@slagle

Hey guys,

Just chiming in here. We’re doing this to alleviate a lot of the pressure that we see on the platform. Basically we are expanding the number of DB clusters we have. Unfortunately it wasn’t easily migratable (I know migratable isn’t a word lol).

This should really help a lot of things and is a step in the right direction. We can only ask for your patience as we grow thorough this.

Hey, I’m always glad to see server expansion. It wasn’t difficult to see that the load had become too much for the current set up.

But the main thing, thanks for of the comms the last couple of days…

But I have one unanswered question? ?

What exactly does package-mismatch mean? ?

[codytruscott]

@bamarayne

I don’t see a need for anything over 24 to 48 hours old. Take a screen shot if you want to store it local for later T/S. If not, it’s really not needed.

Sometimes you don’t know that you need to track down a billed hours discrepancy from a service company until a few days later. =)

But. Yes. The detailed logging should be opt-in to cut down on resource use.

[JDRoberts]

You may not need it. Somebody else may very well. For that matter, there’s been several times when it has taken support more than 2 days to get back to me, so if they don’t have the event logs that’s a whole separate issue.

Opt-in might be one answer. Alternative logging methods might be another. I can’t imagine taking screenshots every day is one in the 21st century but I guess if there’s somebody who wants to spend time doing that, OK. Choice is good. But taking screenshots every day as the only option doesn’t seem reasonable.

JMO

[keltymd (Matt)]

the ability to export your logs would solve this too. If they only keep 24 hours you could have a job that exports them or jsut the ones you want every day