When I accessed Flurry Analytics on April 28th, it said there was "NO DATA", and I was unable to check the log.
I tried using several different accounts but the situation was the same.
After that I tried again using the same method on April 30th and was able to check the log as usual.
I would like you to advise why I was unable to see any data on April 28th, and if there is going to be any periodical maintenance etc. in the future.
Thank you in advance.
This was the result of an outage due to code released the previous day causing the event logs to be inaccessible for approximately 18 hours. We do not expect any reoccurrence of this issue.
Related
Recently we've had one of our web services fail its Azure database backups with the following error.
The specified point in time, '11/24/2021 16:57:50', is not valid for database 'R6tvK6Nc9W'. Valid points in time should be between '11/24/2021 16:59:48' and '11/24/2021 17:03:50' inclusive.
The timestamps vary, but in each case the top of the time range is exactly 6 minutes from the specified time. The error is coming from Azure, and up until recently everything has been working fine without any issues, no major code changes have occurred on our end for some time.
I'm more or less new to Azure, having only recently taken over from the previous developer who worked on this, so if this is something obvious or common I apologise, it wasn't covered in the handover I was given.
Check if the database is part of Failover Group and remove it before starting the restore.
I published a new version of my Chrome extension on the 29th of October, and the publishing process is still pending since (17 days). I tried to cancel and republish, I even wrote to the Google dev team, but nothing changed.
Most of the time, publishing takes a few hours only, but on a few occasions I had to wait between 3 and 10 days to get the update approved.
But more than 17 days now seems absolutely crazy. I don't know how I can provide a reliable experience for my users with such random and long delays (what if there's a bug I need to fix?).
Does anyone know why this process takes sometimes long? Is there anything I can do to change that? How do other extensions handle these delays?
I have scheduled the Azure ML Batch Job via Azure Data Factory to run daily at 12:00 AM UTC.
Don't know what is the issue, but it is failing for every month's 3rd day, otherwise it runs perfectly.
Anybody facing same issue?
For September
For October
It looks like ADF is successfully invoking ML and reporting back the "not converging" error. Could there be something specific in the input data that could cause this problem? Is there anything in the ML model that is handling dates as monthly that could be impacted by daily execution, around the start/end of the month (especially if there is any data offset or delay)?
It is likely data related. The error is being returned from the batch execution system when the model is trying to score the data. I would look for duplicate Ids being inserted. Or any specific data that is being passed that could cause problems for this model.
Having the job id and the Azure region this is running would help us look up the specific error.
I've been using functions for a while and it seems the longer the Function is around, the less accurate the Portal logs are. When I first was using my functions for maybe 3 months everything monitor/logging wise was fine. Over time things starting getting less accurate.
Now I see the real logs by going to the ms azure storage explorer and checking the AzureWebJobsStorage.
First when I bring up the code/logs the last log it brings up isn't accurate. It will be from a few days ago usually, or the last error. When it triggers though, it does get the live feed. This isn't that big a deal, it's the monitor being inactive that and not being able to see the logs from that which is bad. I suppose I just use the Azure Storage explorer.
Monitor Invocation Logs, always seems a few days behind. This used to be accurate, but the last month or so, it's always a few days behind
Dan,
The local, file based logs, exist primarily to support the portal experience, so the behavior you're observing on the log window is expected as the logs are not written by the runtime as part of the normal invocation process, but only when you're actively developing/testing on the portal.
The issue you're experiencing with the monitor is due to a regression that has been patched and should be fully rolled out today (you can see more details here)
We've been listening to feedback on our logging capabilities, and there has been a lot of investment in that area, resulting in the recently announced built in integration with Application Insights. That integration addresses some of the pain points you've brought up as well as other issues, so I'd strongly recommend trying it out. You can find more information about it here.
I have 5 Azure SQL Database instances all located under the same SQL Server instance in Azure. When I view the "Resource Health" section of any of the databases, I am seeing quite a bit of the messages "we're sorry, your sql database is unavailable" which is concerning.
I am trying to understand though,is this just normal Azure SQL downtime/outage or if there is an issue in my database itself. Looking at the past logs, the DTU usage, etc. do not show any unnecessary strain on the system or usage above my allotted threshold. Yet, I am seeing databases marked as down for several minutes at a time daily from the past two weeks of history that Azure provides.
Excerpt from Conversation with Azure Support
This is bug with portal, which is causing to show these error messages.This has nothing to do with Availability of database..
this will be fixed soon
In Mail :
As discussed the error messages that you saw are due to a known Bug in Azure Postal which should be fixed soon.
Thank you for your time on the phone. It was my pleasure to work with you on this issue.
As agreed over call this support incident will now be archived. If you have further problems within the scope of this issue, please do reopen the support case.