If Forge would have been adopted within Atlassian for any serious core feature development (to a similar degree as P2 in DC) with the proper feedback loop from the internal developers, Forge would be already looking more like “Connect on EKS and RDS inside Atlassian controlled infrastructure”, rather than the overengineered Lambda-based solution with uncontrollable and uncapped consumption-based pricing.
Instead, we are still waiting for container-based runtime, which maybe will ship just a few months before the final Connect deprecation.
The simplest and fairest solution is to not charge vendors for log output that they did not ask for. I would suggest making Atlassian/Forge derived logs free or able to be stopped.
We currently use a third-party logging service for streaming logs. We have a defined monthly plan and we pay a fixed amount. If the capacity is exceeded, we get an alert and they start dropping logs. This provides complete cost control and it allows us to respond to spikes as we deem appropriate.
For services like logging, having a cutoff slider would be fantastic. In addition to excluding Atlassian-generated logging, let vendors set their maximum log ingestion per month (bonus points if you display the expected cost next to it), and don’t log (or bill) for logging attempts above that limit.
If a vendor configures a maximum of 10 Gb of log ingestion per month, I would expect the actual accepted logged data to be 10 Gb plus however much additional logging Atlassian itself forces to be logged. (If I am paying for 10 Gb of data, I want to be able to see 10 Gb of my data, plus whatever data of yours that may also be included.)
It’s the end of the week here in NZ so I just wanted to share a few updates on our thinking:
We’re looking into the Forge Remote/System logs as a priority. Either we’ll change these over to be metrics (which are free), or exclude system generated logs from your app’s usage.
With respect to suppressing logging for certain customers, log levels etc. we don’t have any specific plans here but we do have feature flags coming soon (expressions of interest) which you will be able to use to adjust logging levels from developer console if you wish.
The broader topic of setting alerts/limits/controls on spiky costs is something we’ll keep exploring. We’ll have alerts for apps approaching the free threshold but keen to get more feedback on what should happen after the threshold has been reached.
I had a chat with @AdamMoore and here is the update on the same.
For Forge remote logs, we don’t plan to charge developers. However, Atlassian will also stop ingesting and storing these logs going forward. As a result, Forge remote-specific logs won’t be visible to developers, and they also won’t incur any cost.
When a customer disables log sharing, Atlassian will continue ingesting those logs to help developers diagnose and resolve customer issues that occurred in the past where customers can enable log sharing for the required duration. Overall, developers will continue to be charged for logs, regardless of the customer’s log-sharing preference.
Agile Hive Cloud runs completely on Atlassian and we are facing the detail, that logging seems more expensive than computation? That’s blatantly insane. No platform has that high costs for logging.
The more logs the easier we can help customers during runtime on their site. We already keep it compact and don’t log in loops in example, only after loops. Still we are facing a lot of logging to debug the application in case of incidents. Especially when running into error codes from Atlassian APIs, which happens frequently. So a lot of errors from third parties like Atlassian API lead to lots of logs that result in costs. That does not make sense in order to deliver a reliable monitoring.
On top of that we can only access logs for 2 weeks in the past on the Forge console now? What costs so much? We get almost nothing out of it. 1GB is nothing on large customer sites with frequent usage of 100k users and millions of issue edits every month. I prefer to push the logging into our own tooling in GCP which is way cheaper and gives us more insight and statistics per site and alerting. The current log system is errors prone, often fails like last week where we got no logs but still charges for processing logs? And the limits are very low. It’s almost impossible to help large enterprise sites because the there are no log statistics over time. We cannot keep track if measurements in our app work out.
I am looking into pushing everything into our monitoring in GCP and hope that it can be even easier in the future. And why does that also result in costs? Can logging into a remote sink happen more direct?
Hi Atlassian team / @AdamMoore / @ChandanaMeka - Any updates on the implementation of controls for spiky costs?
We need to forecast our expenses as soon as possible, and without knowing whether Atlassian will provide a safety mechanism to prevent potential spiky costs (which could drive many small and medium app developers to bankruptcy), it becomes very difficult to model different scenarios for our business within this new model (which on its own will already be much more expensive than any other provider currently used by the developer community)
I note that although Forge live billing starts in just three weeks time, I see that my app is still generating plenty of logs in the console for Forge Remote usage.
Can you let the community know if Atlassian is going to be able to address this before live billing starts?
Hi @scott.dudley, we are working on this currently and we will ensure that forge remote logs will be excluded from the usage and charges before live billing starts.